Re: GSoC: Libreoffice Theme WIN (not getting stdout, cannot do printfdebugging)
On 01.07.2024 23:42, Sahil Gautam wrote: Hi, I successfully built libreoffice on windows using LODE. The problem is that I cannot see stdout on the terminal, or in vscode's terminal. I rely on that for checking if opening this dialog trips this breakpoint or not, and how many times does it do so. using a debugger seems a good choice, but it's a hassle considering that UI can trigger a function changing colors n times, and I don't want to press F5 n times, it's not feasible. Is there any way to get the stdout on the terminal? Since you develop on Windows, a natural choice would be using Visual Studio for debugging. And it allows setting a special kind of breakpoints, which outputs a string (maybe with different variables values), and continued execution. This is in a sense superior to printf, because it doesn't need a modification and compilation, but you can do it at the runtime, changing the output dynamically, enabling and disabling the breakpoints. The downside is its lower performance; so e.g. putting such a breakpoint to e.g. OUString constructor would make your debugging session crawl and last for days :-) In a reply to another mail, I mention that there is a proper console mode on Windows since version 6.3. However, Cygwin's mintty has never beed affected by the problem, so if you run from mintty, it should output properly, even if you run soffice.exe. In Windows' cmd.exe, calling soffice without an extension runs soffice.com automatically, and also should give the proper console output. But of course, this is all general considerations, and to advise something concrete, specifics of your problem are required. -- Best regards, Mike Kaganski
Re: [GSoC] Comments in Sidebar Deck: Weekly Update
Hello everyone, I spent most of the last week trying to fix a bug where LO crashed when I undo after deleting comment(s). This just got fixed yesterday, thanks to Sarper. While debugging I noticed another bug in `CommentsPanel::addComment`, which was taking the last item from `SwPostItMgr::mvPostItFields` to create a new comment. While `SwPostItMgr::InsertItem` indeed adds a new comment at the end of the vector, but during the whole processing of the comment, `mvPostItFields` is also getting modified (which I realized later). So I had to modify `addComment` to get the meta-data of the newly added post-it via its id and display it in the sidebar deck. I also modified other parts of the code like using post-it id in the map (instead of `SwAnnotationWin) to get the corresponding comment in the sidebar deck. With this, any change made to comments via the annotation window (in the margin) will be reflected in the new comments panel in the sidebar. Now I'll be working on adding the ability to modify the comments directly through comments panel and synchronize annotation window with it. Thanks, Mohit
Re: GSoC: Libreoffice Theme WIN (not getting stdout, cannot do printfdebugging)
On 02.07.2024 11:07, Jim Raykowski wrote: For me, running with instdir/program/soffice.exe doesn't show std::cout output in the terminal. Running with instdir/program/soffice.bin does. https://mikekaganski.wordpress.com/2018/11/21/proper-console-mode-for-libreoffice-on-windows/ -- Best regards, Mike Kaganski
Re: GSoC: Libreoffice Theme WIN (not getting stdout, cannot do printfdebugging)
For me, running with instdir/program/soffice.exe doesn't show std::cout output in the terminal. Running with instdir/program/soffice.bin does. On Mon, Jul 1, 2024 at 9:15 PM Heiko Tietze wrote: > > In cygwin environment, don't you run instdir/program/soffice.exe? Works well > here. > > > On 01.07.24 8:42 PM, Sahil Gautam wrote: > > Hi, I successfully built libreoffice on windows using LODE. The problem is > > that > > I cannot see stdout on the terminal, or in vscode's terminal. I rely on > > that for > > checking if opening this dialog trips this breakpoint or not, and how many > > times > > does it do so. using a debugger seems a good choice, but it's a hassle > > considering that UI can trigger a function changing colors n times, and I > > don't > > want to press F5 n times, it's not feasible. Is there any way to get the > > stdout > > on the terminal? I tried ./..soffice > log.file, but didn't get anything. > > If not > > then n times F5 (continue the debugger) will be the only option. I use > > `std::cout << "string here" << std::endl;` in the function calls. Regards > > Sahil > > Gautam
Re: GSoC: Libreoffice Theme WIN (not getting stdout, cannot do printfdebugging)
In cygwin environment, don't you run instdir/program/soffice.exe? Works well here. On 01.07.24 8:42 PM, Sahil Gautam wrote: Hi, I successfully built libreoffice on windows using LODE. The problem is that I cannot see stdout on the terminal, or in vscode's terminal. I rely on that for checking if opening this dialog trips this breakpoint or not, and how many times does it do so. using a debugger seems a good choice, but it's a hassle considering that UI can trigger a function changing colors n times, and I don't want to press F5 n times, it's not feasible. Is there any way to get the stdout on the terminal? I tried ./..soffice > log.file, but didn't get anything. If not then n times F5 (continue the debugger) will be the only option. I use `std::cout << "string here" << std::endl;` in the function calls. Regards Sahil Gautam OpenPGP_signature.asc Description: OpenPGP digital signature
New Defects reported by Coverity Scan for LibreOffice
Hi,
Please find the latest report on new defect(s) introduced to LibreOffice found
with Coverity Scan.
300 new defect(s) introduced to LibreOffice found with Coverity Scan.
175 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 20 of 300 defect(s)
** CID 1608034:(LOCK)
/filter/source/config/cache/typedetection.cxx: 1046 in
filter::config::TypeDetection::impl_detectTypeFlatAndDeep(utl::MediaDescriptor
&, const std::vector> &, bool, rtl::OUString &)()
/filter/source/config/cache/typedetection.cxx: 1045 in
filter::config::TypeDetection::impl_detectTypeFlatAndDeep(utl::MediaDescriptor
&, const std::vector> &, bool, rtl::OUString &)()
*** CID 1608034:(LOCK)
/filter/source/config/cache/typedetection.cxx: 1046 in
filter::config::TypeDetection::impl_detectTypeFlatAndDeep(utl::MediaDescriptor
&, const std::vector> &, bool, rtl::OUString &)()
1040
1041 OUString sDeepType = impl_askDetectService(sDetectService,
rDescriptor);
1042
1043 // d)
1044 if (!sDeepType.isEmpty())
1045 return sDeepType;
>>> CID 1608034:(LOCK)
>>> "~unique_lock" unlocks "aLock" while it is unlocked. [Note: The source
>>> code implementation of the function has been overridden by a builtin model.]
1046 }
1047 catch(const css::container::NoSuchElementException&)
1048 {}
1049 // e)
1050 }
1051
/filter/source/config/cache/typedetection.cxx: 1045 in
filter::config::TypeDetection::impl_detectTypeFlatAndDeep(utl::MediaDescriptor
&, const std::vector> &, bool, rtl::OUString &)()
1039 }
1040
1041 OUString sDeepType = impl_askDetectService(sDetectService,
rDescriptor);
1042
1043 // d)
1044 if (!sDeepType.isEmpty())
>>> CID 1608034:(LOCK)
>>> "~unique_lock" unlocks "aLock" while it is unlocked. [Note: The source
>>> code implementation of the function has been overridden by a builtin model.]
1045 return sDeepType;
1046 }
1047 catch(const css::container::NoSuchElementException&)
1048 {}
1049 // e)
1050 }
** CID 1608033: Memory - illegal accesses (INTEGER_OVERFLOW)
/sc/source/core/data/table3.cxx: 2056 in ScTable::DoSubTotals(ScSubTotalParam
&)()
*** CID 1608033: Memory - illegal accesses (INTEGER_OVERFLOW)
/sc/source/core/data/table3.cxx: 2056 in ScTable::DoSubTotals(ScSubTotalParam
&)()
2050
2051 for (sal_uInt16 nLevel=0; nLevel>> CID 1608033: Memory - illegal accesses (INTEGER_OVERFLOW)
>>> "aRowEntry.nGroupNo", which might have underflowed, is passed to
>>> "rParam.nSubTotals[aRowEntry.nGroupNo]".
2056 SCCOL nResCount =
rParam.nSubTotals[aRowEntry.nGroupNo];
2057 // result functions
2058 ScSubTotalFunc* pResFunc =
rParam.pFunctions[aRowEntry.nGroupNo].get();
2059
2060 if (nResCount > 0) //
otherwise only sort
2061 {
** CID 1608032:(INTEGER_OVERFLOW)
/sw/source/core/doc/gctable.cxx: 446 in lcl_MergeGCLine(SwTableLine *,
::GCLinePara *)()
/sw/source/core/doc/gctable.cxx: 444 in lcl_MergeGCLine(SwTableLine *,
::GCLinePara *)()
*** CID 1608032:(INTEGER_OVERFLOW)
/sw/source/core/doc/gctable.cxx: 446 in lcl_MergeGCLine(SwTableLine *,
::GCLinePara *)()
440 nBoxes = pLn->GetTabBoxes().size();
441 }
442
443 // ATTENTION: The number of boxes can change!
444 for( SwTableBoxes::size_type nLen = 0; nLen <
pLn->GetTabBoxes().size(); ++nLen )
445 if( !lcl_MergeGCBox( pLn->GetTabBoxes()[nLen], pGCPara ))
>>> CID 1608032:(INTEGER_OVERFLOW)
>>> Expression "--nLen", which is equal to 18446744073709551615, where
>>> "nLen" is known to be equal to 0, underflows the type that receives it, an
>>> unsigned integer 64 bits wide.
446 --nLen;
447 }
448 return true;
449 }
450
451 // Clean structure a bit
/sw/source/core/doc/gctable.cxx: 444 in lcl_MergeGCLine(SwTableLine *,
::GCLinePara *)()
438
439 pLn = pLine;// and set up anew
440 nBoxes = pLn->GetTabBoxes().size();
441 }
442
443 // ATTENTION: The number of boxes can change!
>>> CID 1608032:(INTEGER_OVERFLOW)
>>> Expression "++nLen", which is equal to 0, where "nLen" is known
Re: GSoC: Libreoffice Theme WIN (not getting stdout, cannot do printfdebugging)
Hi, I successfully built libreoffice on windows using LODE. The problem is that I cannot see stdout on the terminal, or in vscode's terminal. I rely on that for checking if opening this dialog trips this breakpoint or not, and how many times does it do so. using a debugger seems a good choice, but it's a hassle considering that UI can trigger a function changing colors n times, and I don't want to press F5 n times, it's not feasible. Is there any way to get the stdout on the terminal? I tried ./..soffice > log.file, but didn't get anything. If not then n times F5 (continue the debugger) will be the only option. I use `std::cout << "string here" << std::endl;` in the function calls. Regards Sahil Gautam On 6/30/24 12:49 AM, Sahil Gautam wrote: Hi, So I was setting up Libreoffice Dev on windows (Yes, windows), I was following the LODE guide from the wiki. I faced this error while running ./autogen.sh checking whether build should auto use hardening compiler flags... no checking whether to build a Community flavor... yes checking whether to sign windows build... no checking for gawk... gawk checking for gawk... /usr/bin/gawk checking for bash... /bin/sh checking for pigz... no checking for gzip... /usr/bin/gzip checking for GNU or BSD tar... tar checking for tar's option to strip components... --strip-components checking how to build and package galleries... internal src images for desktop checking build with or without template files... enable all templates checking for ccache... not found checking for sccache... (cached) not foundchecking whether to build with .NET support... yes checking for dotnet... no checking whether to build with Java support... yes checking whether to treat the installation as read-only... no checking Visual C++... checking VC++ Build Tools and similar... configure: error: no Visual Studio installation found Error running configure at ./autogen.sh line 321. I will try one more time, and If I get some success, then I will write a followup. Also I Installed visual studio 2022 community (this is what I found on the first few links. on a google search) On 28-06-2024 10:37, Sahil Gautam wrote: Hi, I missed the email for the last week, sorry for that. So the patch for gtk was pushed, and the one for QT will be out by tommorrow(+1 day). I spent quite some time with QStyle trying to get it to paint the UI elements, which complicated stuff, and took a lot of time, where it was just palette manipulation (mostly). Also I found that we handle the menubar separately, and it's not drawn via drawNativeControl(...). What is left for QT: - color customization for menus (menubar/window/button/etc done) - adding a listener for instant redraw - And some improvements on the GTK patch (on color coverage). Then I will start with windows vcl plugin. Can't say, but I would be very happy if I get done with windows vcl plugin before the mid term evaluation. In this time I tried setting up macos VM as well, and using quickget (as suggested by Ilmari), it was quite simple. (Though it took years to install neovim via brew, and I had to C^c it every time) Regards Sahil Gautam On 6/11/24 11:44 PM, Sahil Gautam wrote: Hi, so the issue has been resolved,https://gerrit.libreoffice.org/c/core/+/168016/comment/b977e358_def16582/ [Rafael's comment on missing registry entry for LoadDefaultSystemColors]. Now it loads the default colors into the registry once (as expected). On 6/11/24 4:04 AM, Sahil Gautam wrote: Hi went through the design of data flow this week. I found myself running away from the VCL and it's colors, or rather from the question of "how to get 2 way exchange of colors working". https://gerrit.libreoffice.org/c/core/+/168016 Here's the patch [WIP] There is quite some information to keep in the head, I would try to briefly describe it. - So we get colors out of the widget toolkits using the updateSettings() functions. - We have ColorConfig() which gives access to the ExpertConfiguration colors (or colors in the registry
Weekly Status Update 8
Hi, This is my weekly status update for Improving User Experience Around Windows. In this week, read documentations around using rdf meta data and read related C++ files. The goal is to be able to store data directly into the document and read from it. However, this will only be a test implementation for now since it turns out that, the documentation also mentions that as of Openoffice.org version 3.2, rdf metadata is only supported in writer documents at the moment. Best Regards, Aung
