If there are commands or icons that have become invalid due to specification changes, they should be deleted.

Confirm, the logic around FN_CHANGE_THEME [1] and maybe the FN_INVERT_BACKGROUND UNO are not doing well with the new Appearance theme framework.

Clean profile with just the default Automatic appearance theme, and then installing the Office 2003 Blue theme. 

So OPs STR with addition to Calc standard menu of the .uno:ChangeTheme (Toggle between dark and light modes) button control still works-- sort of. As noted it will toggle the fg/bg momentarily but then reverts with sheet scroll.

Then, selecting the Office 2003 Blue theme, and restarting.

As with default Automatic selecting the 'Dark Mode' TB button toggles fg/bg colors for the sheet briefly, until sheet scroll. 

But also the Tools -> Options -> Appearance theme now shifts from the Office 2003 Blue back to the default Automatic theme, but *without restart*, just the fg/bg briefly change.

When the .uno:ChangeTheme button is added to Writer, get a similar mishandling of the theme.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/appserv.cxx?r=ddeeca35d9630f2d3d3afb83a2ec8f21458f6e19#680

Version: 25.2.0.3 (X86_64) / LibreOffice Community
Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069
CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6042e60d69c40d1f307710e60a278cb286d68603
CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Having an easy way to quickly switch between the light and dark UI is a handy feature. It should still be possible (understand this as a bug/regression) but not if we remove the duality for themes as discussed in bug 164970.

i can think of a solution where the .uno:ChangeTheme command also considers whether themes are enabled or not. in case themes are enabled, we change between current theme's light/dark versions (change the appearance option), and show a restart dialog to tell the user that this is required.

in case theme is not enabled, we just follow the old behaviour.

(In reply to Heiko Tietze from comment #3)
> but not if we remove the duality for themes as discussed in
> bug 164970.

I don't think we're really considering doing that. Rather, we're pushing that a fully prepared Appearance theme must provide both a slate of Light and a Dark color definitions. With any undefined 'Automatic' drawn from system, or some fallback heuristic.

(In reply to Sahil Gautam (allotropia) from comment #4)
> i can think of a solution where the .uno:ChangeTheme command also considers
> whether themes are enabled or not. in case themes are enabled, we change
> between current theme's light/dark versions (change the appearance option),
> and show a restart dialog to tell the user that this is required.
> 
> in case theme is not enabled, we just follow the old behaviour.

But in effect, we've been moving toward establishing a 'default' Appearance theme that is *always applied*, ie. not so different from the other Appearance themes, just that its composition is dynamic. Drawing its 'Automatic' values from os/DE 'System' values, but also the ability in UI to force 'Light'/'Dark' override (in some form) of what os/DE reports.

Seems like the UI toggle control UNO for .uno:ChangeTheme or the InvertBackground should be available in all themes, even "default" no theme 'Automatic'. 

Just the implementation question of if the toggle can apply immediately without restart (so as to not disrupt workflow) or as with a full theme change require restart (a bit disruptive).

*** Bug 165343 has been marked as a duplicate of this bug. ***

*** Bug 165110 has been marked as a duplicate of this bug. ***

(In reply to V Stuart Foote from comment #5)
> I don't think we're really considering doing that. Rather, we're pushing
> that a fully prepared Appearance theme must provide both a slate of Light
> and a Dark color definitions. With any undefined 'Automatic' drawn from
> system, or some fallback heuristic.
> 
> But in effect, we've been moving toward establishing a 'default' Appearance
> theme that is *always applied*, ie. not so different from the other
> Appearance themes, just that its composition is dynamic. Drawing its
> 'Automatic' values from os/DE 'System' values, but also the ability in UI to
> force 'Light'/'Dark' override (in some form) of what os/DE reports.
> 
> Seems like the UI toggle control UNO for .uno:ChangeTheme or the
> InvertBackground should be available in all themes, even "default" no theme
> 'Automatic'. 
> 
> Just the implementation question of if the toggle can apply immediately
> without restart (so as to not disrupt workflow) or as with a full theme
> change require restart (a bit disruptive).

makes sense, going ahead with this for the moment

(In reply to Sahil Gautam (allotropia) from comment #8)
> (In reply to V Stuart Foote from comment #5)
> > I don't think we're really considering doing that. Rather, we're pushing
> > that a fully prepared Appearance theme must provide both a slate of Light
> > and a Dark color definitions. With any undefined 'Automatic' drawn from
> > system, or some fallback heuristic.
> > 
> > But in effect, we've been moving toward establishing a 'default' Appearance
> > theme that is *always applied*, ie. not so different from the other
> > Appearance themes, just that its composition is dynamic. Drawing its
> > 'Automatic' values from os/DE 'System' values, but also the ability in UI to
> > force 'Light'/'Dark' override (in some form) of what os/DE reports.
> > 
> > Seems like the UI toggle control UNO for .uno:ChangeTheme or the
> > InvertBackground should be available in all themes, even "default" no theme
> > 'Automatic'. 
> > 
> > Just the implementation question of if the toggle can apply immediately
> > without restart (so as to not disrupt workflow) or as with a full theme
> > change require restart (a bit disruptive).
> 
> makes sense, going ahead with this for the moment


Sounds good. But which gets assigned to the .uno:ChangeTheme action (present on the Calc toolbar or as customized) versus what selecting the Tools -> Options -> Appearance panel for the 'Light' | 'Dark' radio button alternatives to 'System'?

The UNO action applies immediately? While the Appearance panel forces the restart (bcz still needed for consistent rebuild of the color scheme)? 

Or des the Appearance panel RB goes ahead with a toggle, as it used to do from the Application Color panel (but we'll have corner cases of a color not getting applied to UI or document)?

(In reply to V Stuart Foote from comment #9)
> The UNO action applies immediately? While the Appearance panel forces the
> restart (bcz still needed for consistent rebuild of the color scheme)? 
> 
> Or des the Appearance panel RB goes ahead with a toggle, as it used to do
> from the Application Color panel (but we'll have corner cases of a color not
> getting applied to UI or document)?

ok, taking a step back after looking at the code (and reading the tagged comment). the application needs restart in order to apply the theme effectively. showing a restart button on a dialog is fine, but not that great for a toolbar button, the user might be working on something which is "unsaved". sure a "save|don't save|cancel" dialog might show up but that's inconvenience and friction.

considering that we want it to be consistent with the themes implementation, i think of binding it to the application appearance (the radio button in the themes ui) and showing the user a message dialog that he needs to restart in order to  apply the theme.

the uno command also takes an optional theme argument. so if there's an argument then we change theme to that theme, and if there is no argument then we treat this button as an appearance toggle and show a message dialog in both cases.

Would realize it more simple as a switch for the automatic app colors only. The command could be disabled if a theme is in use, or even better if the app background is not automatic. Otherwise the command toggles black and white for app background, and perhaps also the grid color (which has not been done before).

The moon icon seems to have stopped working.
Have you decided to remove this feature?

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ddc3cf99a47cb76e1386783df782e4852a19307a
CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded

Discussed the topic with a friend and we came up with another idea: remove the customization of document background color and use just white/black. Then we can easily switch between. What do you think, Sahil?

(In reply to Heiko Tietze from comment #13)
> Discussed the topic with a friend and we came up with another idea: remove
> the customization of document background color and use just white/black.
> Then we can easily switch between. What do you think, Sahil?

after the themes ui rework (finishing tomorrow latest), we would have three default themes (COLOR_SCHEME_LIBREOFFICE_AUTOMATIC, COLOR_SCHEME_LIBREOFFICE_LIGHT and COLOR_SCHEME_LIBREOFFICE_DARK). removing the document color customization isn't neccessary. since we have default light/dark themes, we just switch between them when the uno command is triggered. and since those themes don't touch the UI colors (just the document colors), we won't need to restart the application. (and if i can read the code right then that's what it does right now, just that the theme names are "Light" and "Dark" instead of the enum like name COLOR_SCHEME_LIBREOFFICE_LIGHT(and DARK).

Heiko i will add you to the patches once they are "ready", we would probably revisit this request and possible approaches then :).

(In reply to Sahil Gautam (allotropia) from comment #14)
> ...we just switch between them when the uno command is triggered.
Meaning you change all appearance attributes. For example, if the Office 2003 Blue theme is used you get the default light (or dark) with the moon.

(In reply to Heiko Tietze from comment #15)
> (In reply to Sahil Gautam (allotropia) from comment #14)
> > ...we just switch between them when the uno command is triggered.
> Meaning you change all appearance attributes. For example, if the Office
> 2003 Blue theme is used you get the default light (or dark) with the moon.

yes, it's a really tricky situation. if the user is using automatic/light/dark (the provided themes) then .uno:ChangeTheme makes sense, otherwise it doesn't like in case of Office 2003 theme. it has a themeName parameter. so maybe we can do this

    if the theme name is provided, we switch to that (if not present => auto)
    if themeName not provided (using as a toolbar button)
        if current theme is one of the automatic => toggle b/w light/dark themes
        else if custom theme => (goto CONFUSION)


CONFUSION:
    1. switching to automatic theme from custom theme would be rude
    2. overwriting the custom theme's document colors would be rude as well
    3. removing document color customization might annoy some users.
    4. separating document theming from application theming at the schemea level
       would increase complexity.

maybe we are looking in the wrong place? so there is another uno command .uno:InvertBackground. maybe what the users want is this and not .uno:ChangeTheme. i tried to add .uno:InvertBackground to the toolbar but couldn't for some reason (will look into that shortly). .uno:ChangeTheme changes theme, and i think toggling between light/dark is the fallback behaviour in case there no theme is passed as argument.

back to Heiko.

The way out of the dilemma is to drop document color from the customization and only have white and dark available, hard-coded. Always default to white and switch to black via .uno:ChangeTheme. If a user wants a pink background the only way would be via page style (with the drawback to have it also in the printout).

(In reply to Sahil Gautam (allotropia) from comment #16)

> maybe we are looking in the wrong place? so there is another uno command
> .uno:InvertBackground. maybe what the users want is this and not
> .uno:ChangeTheme. i tried to add .uno:InvertBackground to the toolbar but
> couldn't for some reason (will look into that shortly). .uno:ChangeTheme
> changes theme, and i think toggling between light/dark is the fallback
> behaviour in case there no theme is passed as argument.
> 

Yes that looks legitimate, and the desired behavior could be supported in UNO, but they need to be adjusted. Both were implemented pre-Appearance theme and look to need to be refined with the additional work. With some tweaks to further support theme selection.

https://opengrok.libreoffice.org/xref/core/sfx2/sdi/sfx.sdi?a=true&r=ebea5ef578bd919ab10d769d2eb27521d2c15012&h=5969#5969

.uno:InvertBackground [1][4] would be the correct UNO to toggle just the document/canvas background. As done for Collabora Online and added to master, IINM its scope was limited to just the fg/bg toggle. And, it did not get as fully exposed to UI.

.uno:ChangeTheme [2][3][4] predated Appearance theme work, but got more completely worked into UI across the modules.

Of the two, it seems like the .uno:InvertBackground would make more sense for the document/canvas background toggle here, and not clear the .uno:ChangeTheme should even survive ongoing refactoring of UI (is the UNO control still useful with the reworked Appearance dialog, what facet of system, light, dark might it control)?

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/171633
[2] https://gerrit.libreoffice.org/c/core/+/148942
[3] https://gerrit.libreoffice.org/c/core/+/166781
[4] https://gerrit.libreoffice.org/c/core/+/171889