[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||6555 --- Comment #4 from Heiko Tietze --- Using a noticeable color produces a faint frame around the thumbnail area. Looks to me as if it should take the Application Background color but is overwritten somewhere else. But I wonder if this area really should take the app colors. It's a dialog/window and should rather use what comes from the system theme. Doing so would also improve bug 99116 talking about high-contrast issues with the start center (special hard-coded colors were used in the past and got removed for bug 136555). The thumbnails might pick the user-defined colors. However, if we use the system window color for the background it might conflict with the document canvas color. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||116 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 --- Comment #3 from Rizal Muttaqin --- (In reply to V Stuart Foote from comment #2) > The "thumbnail" previews are simply not re-created / re-generated on > application color "mode" change (which really is just a static application > of a different set of fixed colors from the "default" theme). So, if it's the method why Draw and Impress ignore those static set of fixed colors? Here I'm assuming the two modules instead take values from the Application Colors' color scheme arbitrarily. Or am I wrong? > That seems kind of a waste of dev effort... I'd rather we expend the effort > on extending the slate of UI widgets that can be controlled by the > Application Color theme. Wasting time is a very relative thing. LibreOffice development puts forward the model of who wants to change something, then he contributes. But I fully support this approach. Application Color must be able to force UI widgets whether to follow the operating system's default UI theming (Let's say this color value will be defined as "default") or custom color. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vstuart.fo...@utsa.edu --- Comment #2 from V Stuart Foote --- The "thumbnail" previews are simply not re-created / re-generated on application color "mode" change (which really is just a static application of a different set of fixed colors from the "default" theme). But the thumbnail preview mechanisim probably should be adjusted to produce a "dark mode" preview, at least for when that was the mode the document was opened in. Otherwise while it should be inexpensive to rebuild the previews--responding to light/dark mode change would require refactoring to handle all the thumbnail views held in a users MRU, essentially reopening each document held in history to rebuild its thumbnail view (1st page of document) and record it back to per-user profile registrymodification.xcu in response to a mode change. That seems kind of a waste of dev effort... I'd rather we expend the effort on extending the slate of UI widgets that can be controlled by the Application Color theme. -- You are receiving this mail because: You are on the CC list for the bug.
