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).