[Libreoffice-bugs] [Bug 136555] StartCenter is inconsistent with dark theme(s)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=136555

--- Comment #32 from Jan-Marek Glogowski <glogow at fbihome.de> ---
(In reply to V Stuart Foote from comment #31)
> Created attachment 166897 [details]
> Windows Grey Eve
> 
> (In reply to Jan-Marek Glogowski from comment #30)
> > (In reply to V Stuart Foote from comment #28)
> > > Created attachment 166895 [details]
> > > Current (2020-10-29) state of things with Adwaita theme on Fedora33
> > > 
> > > Recent (20201029) master/7.1.0.0Alpha1+ RPM parallel installed on Fedora 33
> > > 
> > > Screen clip compare SC of 7.0.2.2 to master/7.1.0 with default Adwaita theme.
> > > 
> > > Same affect for the SC button bar background as on Windows - garish.
> > 
> > Feel free to suggest an other themed color. Currently it uses
> > rStyleSettings.GetWindowColor(), because the default == GetWorkspaceColor()
> > looks worse / too dark and is wrong, because it's the same then the
> > background around the Writer document.
> 
> Sorry but that is just it. The old "Branded" StartCenter did not require
> theming--it was "designed" as a brand--replacing of the old start panel and
> incorporating thumbnail views of documents held internally (to LO profile)
> on the recent documents history. The whole thing was designed to be
> monolithic. Avoiding theming coming in from os/DE.

You already provided the bad variants in your images. I'm not aware the buttons
were not themed, as you can see in the dark images before the patches. Same for
the menu bar.

And also the menu bar in the attachment 166897 is unusable. I didn't touch that
at all. It's the same for the menu bar in the Win 10 high contrast themes. The
background of the menu bar doesn't match the theme and the font color is wrong,
taking notepad as a reference. Also the font color is wrong and I couldn't find
the right one, used in notepad.

> As Windows DWM does not support theming (except when signaling a
> HighContrast mode) there has been no 'Dark mode' to worry about. And
> providing functional themeing for Windows builds requires native code for LO
> to pick up the UWP color schemes and map them for LO use. That remains the
> crux of bug 118320
> 
> Absent needed dev work on that, if using a HighContrast signaled theme it
> collapses colors of the assigned theme components. The best DE theme of that
> means is the GreyEve theme. It actually looks reasonable with these recent
> SC background and text color changes. The main menu receives no contrast.
> Attached clip shows 7.0.3.1 and current 20201030 master (ec1f4d3253) with
> Grey Eve high contrast theme enabled. Note the hardcoded activation of Sifr
> icon theme.
> 
> Until Windows builds can respond to UWP theming, my suggestion would be to
> drop os/DE themeing for the SC and instead devise a static dark mode to
> complement the previous light mode SC "branding" that had existed. Selecting
> one or the other comparing luminance of FG text and BG -- the mix of grey
> scale colors available to the StartCenter UI seems sufficient for both
> flavors of BG, FG and button selections.

I don't understand you. If I select a high-contrast theme in Win 10 most of LO
correctly changes the color. So I don't understand what you mean by this
comment. Is this more in regard to a whole application theming? I'm just
talking about colors here for fonts and parts of the UI.

Regarding a "dark SC", that is currently not possible, because for Linux I'm
not aware this is in any way advertised. The theme engine simply provides other
colors and draws stuff differently, but nothing identifies as dark, except for
the name - sometimes.

For MacOS we would have to swith the whole implementation to Cocoa /
NSDocument, to have a way to support this. If I understood tml_ correctly.

And from all I read about Windows dark mode, there isn't a stable identifier
either currently. AFAIK you wrote somewhere, that Chrome uses some hacks, which
work most times, so I wouldn't even want to walk into this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201031/32f93d2a/attachment-0001.htm>