bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

[Maximiliano Sandoval via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Now that Emacs has a proper GTK header bar it would be interesting to
have some GtkSettings exposed, such as gtk-application-prefer-dark-theme
for example, which would allow to programmatically set dark mode for the headerbar.

Note that there are already some hacks to set the header bar to dark mode, but they depend on X11isms, see https://github.com/bepvte/gtk-variant.el.

--
Maximiliano

[-- Attachment #2: Type: text/html, Size: 1155 bytes --]

bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Maximiliano Sandoval <msandova@protonmail.com> writes:

> Now that Emacs has a proper GTK header bar it would be interesting to
> have some GtkSettings exposed, such as
> gtk-application-prefer-dark-theme for example, which would allow to
> programmatically set dark mode for the headerbar.

We don't have a "proper GTK header bar", only the fallback title bar GTK
uses for window decoration, which is only available on window systems
where server side decorations don't exist (such as Wayland and
Broadway.)

In addition to that, the setting is deprecated, so I think relying on it
to set the stylesheet used for window decorations will not be very
effective.

People will probably start screaming like goats if we enable the
fallback title bar on X as well, since client-side decorations are a
very controversial subject, so the best option would be to utilize the
system-wide settings for that job.

Thanks.

bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[I didn't notice you forgot to CC the bug tracker earlier.  Please use
"Reply All" to reply, so that the bug tracker stays copied in.]

Maximiliano Sandoval <msandova@protonmail.com> writes:

>> Not what I recall, where the GTK developers say libadwatia (not
>> individual applications) is supposed to set a dark stylesheet if the
>> user wants to use one.

>> The right way to enable a dark stylesheet is to open GNOME Tweaks, and
>> set the stylesheet to "Adwatia Dark".

> These two affirmations are not correct.

[..]

> Applications which want to follow the GNOME human interface guidelines
> can make use of libhandy in GTK 3 (where they have to explicitly
> opt-in to follow the user preference) or libadwaita in GTK 4. These
> libraries will listed to the dbus for changes of the
> xdg-desktop-portal backed setting and refresh the stylesheet
> accordingly. Libhandy in fact uses "gtk-application-prefer-dark-theme"
> internally to set dark mode [1].
>
> Only when using lib{handy,adwaita}, the
> "gtk-application-prefer-dark-theme" setting should not be used at all,
> since it conflicts with the user preference.
>
> Emacs is not an application targeting the GNOME environment therefore
> it should probably not use either of these libraries. The way forward
> is to either take care of these steps or provide the tools for the
> users to do it.

That suggests the way forward is to provide a build option which will
let Emacs utilize libhandy, or libadwatia, for the people who use GNOME
and are willing to listen to whatever GNOME tells them.

> Right now it is not possible to declare that Emacs should use a dark
> stylesheet.

No, it is possible.  The proper solution is to tell GTK to use a dark
theme, through either GNOME Tweaks or by using gsettings manually, both
of which are not "hacks".

The latter option is explictly supported by the GTK developers.  The
former is not, but it is in use by so many people (many more than the
people using desktop environments which have added support for this new
XDG protocol, none of which have been released yet), that it's hard to
imagine it going away any time soon.

> In short the "Adwaita-dark" setting in gnome-tweaks is a hack that
> will only cause conflicts with the user's preference and is
> incompatible with time based scheduling for dark mode.

Why would it be incompatible with such a feature?

Thanks.

bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

[Maximiliano Sandoval via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> [I didn't notice you forgot to CC the bug tracker earlier...

Thanks!, I am sorry for the trouble.

> That suggests the way forward is to provide a build option which will
>
> let Emacs utilize libhandy, or libadwatia, for the people who use GNOME
>
> and are willing to listen to whatever GNOME tells them.

That works for me, but I have to stress out that this is not GNOME specific.
Such a patch would only require

```
hdy_init ();
hdy_style_manager_set_color_scheme (hdy_style_manager_get_default (),
                                    HDY_COLOR_SCHEME_PREFER_LIGHT);
```

after `gtk_init ()` is called to opt-in into following the user preference.
Note that this requires libhandy >= 1.5, meaning that there are no stable
releases that support this yet, we will have one before GNOME 42 in march.

> Why would it be incompatible with such a feature?

If you are using Adwaita-dark, whatever color scheme you declare in the
xdg-desktop-portal will be override by it (and thus ignored). The reason
Adwaita-dark is broken is because apps cannot tell that they are in a dark mode,
which leads to broken visuals, e.g. in gedit the highlight for the current line
is white, making text invisible in Adwaita-dark.

How does this affect Emacs? For example you might want to sync emacs' theme with
the headerbar stylesheet, and without hacks it is not possible to tell if emacs
is using a stylesheet that correspond to a dark mode. The only way this is
possible is by reading the xdg backed preference and for doing so, it is
desirable to have emacs being able to declare its own GTK theme.

> The latter option is explictly supported by the GTK developers. The
> former is not...

Those options are there only to avoid breakage with existing setups and they are
not going away as you point out, that does not mean they are *supported*. The
only supported way to tell a GTK 3 app that it should use a dark mode stylesheet
is via the `gtk-application-prefer-dark-theme` setting.

Note that there are two variants of this setting: the global one, which was
retired in gnome-tweaks since it was completely broken, and a per-app setting,
which is the recommended option for apps not using libhandy/libadwaita.

Maximiliano Sandoval R.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, January 25th, 2022 at 8:21 AM, Po Lu <luangruo@yahoo.com> wrote:

> [I didn't notice you forgot to CC the bug tracker earlier. Please use
>
> "Reply All" to reply, so that the bug tracker stays copied in.]
>
> Maximiliano Sandoval msandova@protonmail.com writes:
>
> > > Not what I recall, where the GTK developers say libadwatia (not
> > >
> > > individual applications) is supposed to set a dark stylesheet if the
> > >
> > > user wants to use one.
>
> > > The right way to enable a dark stylesheet is to open GNOME Tweaks, and
> > >
> > > set the stylesheet to "Adwatia Dark".
>
> > These two affirmations are not correct.
>
> [..]
>
> > Applications which want to follow the GNOME human interface guidelines
> >
> > can make use of libhandy in GTK 3 (where they have to explicitly
> >
> > opt-in to follow the user preference) or libadwaita in GTK 4. These
> >
> > libraries will listed to the dbus for changes of the
> >
> > xdg-desktop-portal backed setting and refresh the stylesheet
> >
> > accordingly. Libhandy in fact uses "gtk-application-prefer-dark-theme"
> >
> > internally to set dark mode [1].
> >
> > Only when using lib{handy,adwaita}, the
> >
> > "gtk-application-prefer-dark-theme" setting should not be used at all,
> >
> > since it conflicts with the user preference.
> >
> > Emacs is not an application targeting the GNOME environment therefore
> >
> > it should probably not use either of these libraries. The way forward
> >
> > is to either take care of these steps or provide the tools for the
> >
> > users to do it.
>
> That suggests the way forward is to provide a build option which will
>
> let Emacs utilize libhandy, or libadwatia, for the people who use GNOME
>
> and are willing to listen to whatever GNOME tells them.
>
> > Right now it is not possible to declare that Emacs should use a dark
> >
> > stylesheet.
>
> No, it is possible. The proper solution is to tell GTK to use a dark
>
> theme, through either GNOME Tweaks or by using gsettings manually, both
>
> of which are not "hacks".
>
> The latter option is explictly supported by the GTK developers. The
>
> former is not, but it is in use by so many people (many more than the
>
> people using desktop environments which have added support for this new
>
> XDG protocol, none of which have been released yet), that it's hard to
>
> imagine it going away any time soon.
>
> > In short the "Adwaita-dark" setting in gnome-tweaks is a hack that
> >
> > will only cause conflicts with the user's preference and is
> >
> > incompatible with time based scheduling for dark mode.
>
> Why would it be incompatible with such a feature?
>
> Thanks.

bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Maximiliano Sandoval <msandova@protonmail.com> writes:

> That works for me, but I have to stress out that this is not GNOME
> specific.  Such a patch would only require
>
> ```
> hdy_init ();
> hdy_style_manager_set_color_scheme (hdy_style_manager_get_default (),
>                                     HDY_COLOR_SCHEME_PREFER_LIGHT);
> ```
>
> after `gtk_init ()` is called to opt-in into following the user
> preference.  Note that this requires libhandy >= 1.5, meaning that
> there are no stable releases that support this yet, we will have one
> before GNOME 42 in march.

No worries, we can wait until it is released this March to add such an option.

> If you are using Adwaita-dark, whatever color scheme you declare in
> the xdg-desktop-portal will be override by it (and thus ignored). The
> reason Adwaita-dark is broken is because apps cannot tell that they
> are in a dark mode, which leads to broken visuals, e.g. in gedit the
> highlight for the current line is white, making text invisible in
> Adwaita-dark.

That can be remedied by selecting a different color theme in gedit's
preferences, I think.

> How does this affect Emacs? For example you might want to sync emacs'
> theme with the headerbar stylesheet, and without hacks it is not
> possible to tell if emacs is using a stylesheet that correspond to a
> dark mode. The only way this is possible is by reading the xdg backed
> preference and for doing so, it is desirable to have emacs being able
> to declare its own GTK theme.

There is no "headerbar stylesheet" we control, not even on PGTK.  GTK
only draws decorations in our usage when none are available from the
display server and/or window manager, so it isn't right for us to
advertise a feature for "changing the window decoration color" that
doesn't work as such.

> Those options are there only to avoid breakage with existing setups
> and they are not going away as you point out, that does not mean they
> are *supported*. The only supported way to tell a GTK 3 app that it
> should use a dark mode stylesheet is via the
> `gtk-application-prefer-dark-theme` setting.

No, the gsettings setting is explictly supported inside GTK code, and is
not a by-product of trying to not break existing setups.

Programs which want to follow the new XDG preference for preferring dark
stylesheets should use libadwatia or libhandy.  A configuration option
for Emacs to use that is the right way forward, so I suggest any
interested party to begin hacking on that now.

Thanks.