Created attachment 172558 [details] Screenshot of the problem When using the "in registers" view, the background of those registers is different to that of its content.
Not clear. You need to write all, not assuming it's obvious. Is this about Tabbed UI? That inactive tabs are darker? Which is not a bug.
No, I mean this thing you click on to select a tab in the top row, like the head if you will, has a different background than its content. In other words, the background of "Datei" is different to the background of "Neu", "Öffnen", "Dokumentvorlagen" etc. The result is this weird line between tab header and tab content where the background changes slightly without a borderline. In my opinion, that does not look good. I hope that describes it better, should have made a marker in the screenshot.
I see it in your screenshot, trivial as marked. But again you didn't write what's your OS, some customization like dark mode and what is in Options-View, did you change or left default (also please screenshot). Only written is LO 7.0.5. That being said, I don't see in Linux and Windows with default settings.
Created attachment 172725 [details] Screenshot of the UI settings
The only change I made is that I switched the User Interface to "Tabbed". My version info from "About LibreOffice": Version: 7.0.6.2 Build ID: 00(Build:2) CPU threads: 12; OS: Linux 5.12; UI render: default; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: de-DE 7.0.6-1 Calc: threaded (In the meantime, I updated LibreOffice to 7.0.6.2.) System information: Operating System: Manjaro Linux KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.8-1-MANJARO OS Type: 64-bit Graphics Platform: X11 Processors: 12 × Intel® Core™ i5-10400F CPU @ 2.90GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 As you can see, I am running KDE Plasma, using the Breeze theme by default.
Repro, but only with kf5 UI. Not on Windows either. Arch Linux 64-bit Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 1c1427e81c2463fbc40855adfafa360c13108abb CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 27 April 2022
I had a look today and the background is painted by the Qt styling function. Here it's actually the same color then the toolbar / menubar. Even reading Qt code, it's not obvious for me, why / where this color is selected. Maybe it's a bug in the breeze theme engine? There is a lot of stuff in Breeze, which is not available via the QStyle interface, like the white mouse-over text for buttons and obviously several animations. I tried to adapt the state, but nothing changed the background color. LO could overwrite the background setting with the Window background color for the selected tab...
This is not limited to the Tabbed interface, but also to any tabs in LibreOffice UI. For instance, in Writer go to Format - Paragraph and notice the color of the selected tab.
Created attachment 183138 [details] Screenshot of the patched UI Actually it's not the Tab that has the wrong color, but the tab pane was using the wrong color (for some reason I could not figure out). Both the Tab and the Tab contents need to use DialogColor. See the attached image of the UI with the patch. Here's the patch: https://gerrit.libreoffice.org/c/core/+/141411
FTR the dark theme works as well.
Created attachment 183520 [details] Screenshot gtk3 with https://gerrit.libreoffice.org/c/core/+/141411 v2 and gtk3 Adwaita theme The attached screenshot show how https://gerrit.libreoffice.org/c/core/+/141411 (PS2) affects gtk3 with the Adwaita theme. I'll add a comment to the Gerrit change with some more notes.
(In reply to Michael Weghorn from comment #11) > Created attachment 183520 [details] > Screenshot gtk3 with https://gerrit.libreoffice.org/c/core/+/141411 v2 and > gtk3 Adwaita theme > > The attached screenshot show how > https://gerrit.libreoffice.org/c/core/+/141411 (PS2) affects gtk3 with the > Adwaita theme. I'll add a comment to the Gerrit change with some more notes. Michael, which one it the one with the patch? Both say "without".
FTR I ended up abandoning the patch. I'm setting it back to NEW. Sorry for taking so long to update the ticket status.
(In reply to Stéphane Guillou (stragu) from comment #12) > > The attached screenshot show how > > https://gerrit.libreoffice.org/c/core/+/141411 (PS2) affects gtk3 with the > > Adwaita theme. I'll add a comment to the Gerrit change with some more notes. > > Michael, which one it the one with the patch? Both say "without". The first screenshot is without, the second one with the patch applied. (Sorry for the confusion and the late reply.)
Created attachment 196893 [details] Tabbed Plasma 6 look This, sadly, still exist in: KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Graphics Platform: Wayland Tabs feel totally out of place. It really makes LO look bad & broken in Linux.
Created attachment 197534 [details] Screenshot to compare non-welded and welded version dialog with tab control Related to this ticket, https://gerrit.libreoffice.org/c/core/+/176353 now implements support for using a native QTabWidget in dialogs, and https://gerrit.libreoffice.org/c/core/+/176354 makes use of that for the "Tools" -> "Footnote/Endnote settings" dialog in Writer. Attached is a screenshot showing the difference between the non-native (on the left) and the native version (LO started with env variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set, on the right). This demonstrates that using native Qt widgets could be a potential approach if the Notebookbar .ui files can also use the weld approach. I'm not familiar enough with Notebookbar to say that without diving deeper there first. But in any case, there's more work needed for Qt welding before even looking at Notebookbar makes sense here, as the main window will have to be supported first. See tdf#130857 for Qt welding.
(In reply to Michael Weghorn from comment #16) > (...) This demonstrates that > using native Qt widgets could be a potential approach if the Notebookbar .ui > files can also use the weld approach. > > I'm not familiar enough with Notebookbar to say that without diving deeper > there first. Notebookbar currently does not support the weld approach, see tdf#163988.