Created attachment 179224 [details] Inconsistent page background colors between modules. Using a dark content color scheme (Tools > Options > Applications Color. In the color scheme section, select LibreOffice Dark) does not darken the page preview in the Start Center. There is even an inconsistency there. Writer and Calc files still show dark areas of the page, while Draw and Impress documents look dark. The document preview in Start Center should respect the color scheme we've chosen. There is tdf#51535 which was fixed but don't know the difference as the option mentioned there is different with current master/fresh/still LibO version
"Writer and Calc files still show dark areas of the page, while Draw and Impress documents look dark." I mean Writer and Calc files show white/light area of the page, while Draw and Impress look dark.
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.
(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.
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.
Rather than using an arbitrary hard-coded color for the dialog we should prefer the system theme, which should also fit with what was used to generate thumbnails in most cases. Suggestion is to not redraw thumbnails (on what basis?). Could imagine making this a DUP to bug 99116 but in the end it's another aspect: "Make sure thumnails are readable".
(In reply to V Stuart Foote from comment #2) > 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. ... and that is a no-go, since it will introduce new "hangs" trying to access documents on inaccessible media (or via slow connection), etc.
(In reply to Heiko Tietze from comment #5) > Rather than using an arbitrary hard-coded color for the dialog we should > prefer the system theme, which should also fit with what was used to > generate thumbnails in most cases. > So, what are the "system theme" colors on Windows? On macOS? We can't consume a theme color that is not delivered. The hard-coded colors in the SC remain necessary to some extent--with a full slate of widget color assignments to supplement the 'Automatic' values as done for the LibreOffice Dark "Application Color" panel. > Suggestion is to not redraw thumbnails (on what basis?). Bcz as recorded to user profile the thumbnail preview is a static snapshot of the document when it was last fully opened and saved. Changing it would mean reopening the document (separate threads of course).
(In reply to V Stuart Foote from comment #7) Please do not consider re-generation of thumbnails only to account for the changed theme. You will soon run into requirement to touch files every time, just because you have no way to know that the theme is not changed: was it changed by editing registrymodification? by automatic choice based on system configuration change? by changed defaults in an updated version? But OTOH, we use PNGs in thumbnails; and the PNGs *do not* use transparency. We could think how to use transparency for the document background instead, and have it ready for rendering on any theme-defined background then.
(In reply to V Stuart Foote from comment #7) > (separate threads of course). Let me clarify why even separate threads is a no-go. We have a long-standing need to implement separate thread(s) to get the documents availability and password-protected state (e.g., tdf#101302). But both those tasks do not require full loading of the documents, only accessing on disk, and reading some small part. OTOH, drawing a thumbnail is necessarily only possible after full load and layout. Loading of the documents is *much* longer process, sometimes taking tens of minutes with large documents; the loading is implemented with heavy use of our central SolarMutex, only allowing to load one document at a time; and sometimes loading crashes or hangs. When user opens a document, they see which document fails, and have some control over that; they may decide to not open it again after crash, or try to do something smart (open using some specific filter). When the loading would be attempted automatically just to make thumbnails consistent with the theme, you are in trouble.
(In reply to Mike Kaganski from comment #8) > ... > But OTOH, we use PNGs in thumbnails; and the PNGs *do not* use transparency. > We could think how to use transparency for the document background instead, > and have it ready for rendering on any theme-defined background then. +1 (In reply to Mike Kaganski from comment #9) > (In reply to V Stuart Foote from comment #7) > > (separate threads of course). > > Let me clarify why even separate threads is a no-go. Yes I'm convinced, and rendering the thumbnail previews held in user profile history of MRU with transparent bg would allow the SC to respond with a theme appropriate backing color.
*** Bug 148716 has been marked as a duplicate of this bug. ***
I didn't realize a ticket for this existed. I'll post my description here in case it helps describe the issue: "When I launch LibreOffice the main app, not a specific one like Writer or Draw it will show a bunch of previews for recent files. The issue is that I am using dark mode and all of my documents are dark themed but the previews seem to be inverted and show white mode. This does not match what the documents actually look like when opened. Preferably the document previews would show what the document would actually look like if using dark mode. I have stopped using the main LibreOffice app and go directly into Write, Draw, Calc etc instead because I don't like being visually blasted by most of my screens showing white documents." Thanks for all of your hard work.
(In reply to V Stuart Foote from comment #10) > (In reply to Mike Kaganski from comment #8) > > We could think how to use transparency for the document background instead, > > and have it ready for rendering on any theme-defined background then. > +1 Sorry, I don't get how having transparency would solve the issue. Once bug 99116 is resolved and we don't use a static grey, what happens for a document with automatic white background and automatic dark text? Dark text on dark mode Start Center background? I might be missing something, but my opinion is that the Start Center previews should match "what the document would look like if printed". In which case, a single thumbnail would suffice. In any case, the inconsistency reported in comment 0 needs fixing.
*** Bug 151411 has been marked as a duplicate of this bug. ***