Subject: Re: bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

From: Eli Zaretskii <[email-masked]>
Date: Fri, 07 Mar 2025 14:06:16 +0200

> Date: Fri, 7 Mar 2025 08:53:25 -0300
> Cc: Eli Zaretskii <[email-masked]>, Artur Malabarba <[email-masked]>
> From: Mauro Aranda <[email-masked]>
> 
> 
> Eli Zaretskii <[email-masked]> writes:
> 
>  >> From: Artur Malabarba <[email-masked]>
>  >> Cc: [email-masked]
>  >> Date: Wed, 27 Jan 2016 20:20:43 +0000
>  >>
>  >> > Then it would make sense to find a way of switching a theme without
>  >> > changing the frame's background color, if that's possible (i.e. if the
>  >> > new theme keeps the same background color).  If there's a function
>  >> > missing for that, I'd suggest to add one.
>  >>
>  >> How about just running that form only when necessary (i.e., only if the
>  >> disabled theme actually sets the frame `background-color')?
>  >
>  > Yes, something like that.  Or maybe add a new switch-theme API that
>  > receives both the old and a new theme, and changes the background
>  > color only if the new theme sets a different one.
> 
> With the provided recipe, I only see a flash at the scroll-bar
> position, unlike in older versions.
> 
> I'll be testing the attached patch for a while, which introduces a
> new switch-theme command.

Thanks.

Would it be a better UI if instead of prompting with

  Enable custom theme:
  Disable custom theme:

we would prompt like this:

  Switch off theme (default none):
  Switch on theme:

I think this order is preferable, since "switch-SOMETHING"
conceptually means turn off OLD, then turn on NEW, not the other way
around, even if the implementation does it in the reverse order for
some technical reasons.