Bug 148282 - Make sure thumbnails in start center are readable
Summary: Make sure thumbnails in start center are readable
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 148716 (view as bug list)
Depends on: 99116
Blocks: Start-Center
  Show dependency treegraph
 
Reported: 2022-03-30 22:35 UTC by Rizal Muttaqin
Modified: 2022-10-10 09:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Inconsistent page background colors between modules. (83.74 KB, image/png)
2022-03-30 22:35 UTC, Rizal Muttaqin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rizal Muttaqin 2022-03-30 22:35:58 UTC
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
Comment 1 Rizal Muttaqin 2022-03-30 22:37:33 UTC
"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.
Comment 2 V Stuart Foote 2022-03-30 23:26:38 UTC
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.
Comment 3 Rizal Muttaqin 2022-03-30 23:35:40 UTC
(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.
Comment 4 Heiko Tietze 2022-03-31 07:24:31 UTC
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.
Comment 5 Heiko Tietze 2022-04-07 13:00:49 UTC
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".
Comment 6 Mike Kaganski 2022-04-07 13:12:28 UTC
(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.
Comment 7 V Stuart Foote 2022-04-07 13:43:39 UTC
(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).
Comment 8 Mike Kaganski 2022-04-08 06:01:17 UTC
(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.
Comment 9 Mike Kaganski 2022-04-08 06:11:52 UTC
(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.
Comment 10 V Stuart Foote 2022-04-08 12:24:20 UTC
(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.
Comment 11 V Stuart Foote 2022-04-22 16:29:31 UTC
*** Bug 148716 has been marked as a duplicate of this bug. ***
Comment 12 barrett.c5 2022-04-22 17:57:19 UTC
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.