Description: after updating to 25.2, i found that all my presentations have a black-on-black issue for the non-master slides. this issue shows up when the desktop environment is set to dark mode. Steps to Reproduce: 1. switch to gnome and set the desktop environment to dark mode 2. open an impress presentation template 3. open some non-master (slave?) slide Actual Results: the slide background is dark, but before 25.2/theming it was white. the document itself doesn't have the dark background color set, but impress shows it this way because DOCCOLOR is set to a dark color. Expected Results: the application shouldn't misrepresent the document/presentation colors as the visual appearance is used as a reference when creating the slides. 'give me back my white background background color' ;) Reproducible: Always User Profile Reset: No Additional Info: ---
Dark document canvas is expected with dark themes (bug 152184 and other). What should not be affected is export, print, and in case of Impress the presentation mode. And the issue here is that our dark grey is also active in presentation mode. Rather than tweaking the document color to always have a white document canvas by default, we should change the presentation mode. Or introduce a color that is used in this particular case.
@htietze that would be Bug 38065 then, if you interpret it generously. But I tend to disagree, that changing Impress main view document background colors globally (i.e. outside document author control) is a good idea. It will simply break too many non-trivial existing documents, in my experience - and with current Theming work, that's harder for users to recover from.
How about changing the default template resp. the default values for no template?
Kind of agree with Heiko here. The theme framework needs to expand the description of additional elements--for UI and document model--to migrate previous WYSIWYG of presentation and print/publication (bug 38065). While still responding to os/DE Light/Dark color sense. I have to expect that some breakage is going to occur working with existing ODF documents, but that we will end up with more granular control over both UI and document content. All under curated color scheme of Appearance theme authors, with reasonable response to os/DE color sense.
First off, let's confirm there's currently a problem with (lots of) existing presentations. Just done so. I see the usefulness of having the fullness of the UI respond to theming (in fact I love the dark-grey Writer page background in a dark desktop theme - looks & feels great!). But the current UX for Impress is IMO just bad, for anything but the empty, non-templated document. Even some of our built-in templates are utterly unusable with dark themes, with invisible-or-barely-visible text (e.g. blueprint plans, dna, focus (borderline contrast)). Add to that the issues with slideshow, printing, and export - even the thumbnail document preview PNG saved with the document (and used by file managers to render a preview image) uses the saving user's current theme document background color - I dare say this is (for Draw/Impress) more broken than working currently. UX advise greatly appreciated, in particular how to make existing presentations load & render properly - without users having to figure out why text is black-on-black, and then (once they've realized that) globally switching their LibreOffice theme.
My proposal in https://gerrit.libreoffice.org/c/core/+/183118 works for new presentations and does neither change the theming nor any colors. On the downside it does not help for existing presentations (we should not touch the background fill style on loading) and for 3rd party or self-made templates. Some templates still use black fonts on dark background on the notes view. The outline view uses black font on dark background, which is a different issue.
(In reply to Heiko Tietze from comment #6) > My proposal in https://gerrit.libreoffice.org/c/core/+/183118 works for new > presentations and does neither change the theming nor any colors. > > On the downside it does not help for existing presentations (we should not > touch the background fill style on loading) and for 3rd party or self-made > templates. Some templates still use black fonts on dark background on the > notes view. This is quite a big downside.
Sahil's solution in https://gerrit.libreoffice.org/c/core/+/183071 makes the document canvas in Writer and all other modules white. Not sure what solution is worse.
(In reply to Heiko Tietze from comment #8) > Sahil's solution in https://gerrit.libreoffice.org/c/core/+/183071 makes the > document canvas in Writer and all other modules white. Not sure what > solution is worse. Personally I don't know what the big deal with that would be as a dark background is unusual anyway. I would say if a user chooses an unusual way to work they should be prepared to explicitly activate it.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ddfce993c3d833171b92980476b11c985fb7693d tdf#165803 use COL_WHITE for DOCCOLOR for both light and dark modes It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Sahil, I tested your patch a bit, and I found a side-effect it's causing: with dark appearance, it's very hard to see the comment line in Writer. I think this is really not desirable. Is there a way to make the scope of this fix only apply to Impress ?
Created attachment 199929 [details] Comment in Writer ( after vs before )
(In reply to Xisco Faulí from comment #12) > Created attachment 199929 [details] > Comment in Writer ( after vs before ) but isn't that how it is supposed to look on light document? i don't think this is a blocker as there is nothing 'unusual' here. i can think of a quick solution here. if the application is in dark mode but the dark mode is not set explicitly and is instead set because the desktop environment is in dark mode, then use white as dark background. if however the user has chosen dark appearance explicitly, we use the good old dark color? however if you don't see it as a blocker, i would say we don't further complicate the things for a temporary fix. in the next week's design meeting we will be finalizing a new user interface for appearance tab https://bugs.documentfoundation.org/show_bug.cgi?id=164970. the new interface allows the user to disable theming, disable it for the document, make the document follow the application appearance or just use the plain old white appearance forever.
(In reply to Sahil Gautam (allotropia) from comment #13) > (In reply to Xisco Faulí from comment #12) > > Created attachment 199929 [details] > > Comment in Writer ( after vs before ) > > but isn't that how it is supposed to look on light document? No, normally the comment connector is a brownish colour, try it out.
Created attachment 199930 [details] dark vs light
Considering Writer is much more used than Impress, I would expect more users will be affected by this issue, so in a way, it could be considered a blocker
Comment colors were adjusted to light/dark variants for bug 61242. The screenshot not only has low contrast for the connector lines but also breaks the gradient on the comment panel itself (important as feedback for selection) and makes the overall design too light. Likewise the grid line color in Calc we probably have to adjust all colors related to the document canvas. I still dislike this solution and recommend to figure out where Impress replaces COL_AUTO with DOCCOLOR for the slides.