bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maximiliano Sandoval
Subject: bug#53457: 29.0.50; pgtk: [Request] Expose GtkSettings to emacs
Date: Tue, 25 Jan 2022 11:04:36 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]