Re: How to detect a gtk desktop programmatically

[jtojnar gmail com]

On Wed, 2020-04-29 at 20:16 -0400, Tres Finocchiaro via desktop-devel-
list wrote:
> Which is why I assume the old environmental variable has historically
> been so useful, it suggests they're not only available, but also in-
> use.

But it does suggest no such thing. It only says the session was started
using gnome-session. You could, in theory, run something like Qt-based
LXQt desktop environment using gnome-session and the variable would be
still set. And what is worse, as you yourself noticed with Xfce, not
all GTK-based desktop environment use gnome-session, so the absence of
the variable does not rule out the preference for GTK either.

> > XDG_SESSION_TYPE [offers] insight into whatever technology that
> > desktop is using
>
> Ubuntu 18.04 only returns "x11" for that value.

The technology this refers to is the display server I talked about
earlier – the main technology the display environment cares about.

> > Nothing about "ubuntu:GNOME" is "indicative of Gtk", it's stating
> > the fact your running Ubuntu's modified GNOME session.
>
> Right, but projects are already switching to it because it's more
> reliable than nothing at all.

The glib-networking example you linked does not care about GTK, it care
s about GNOME (specifically gsettings-desktop-schemas so it can get the
proxy configuration).

If something used GNOME_DESKTOP_SESSION_ID to detect preference for
GTK, it was simply broken.

> > Convince every desktop session to export "OPENJDK_HEY_IM_GTK" and
> > look at that. - and then wait 4/5 years for that to trickle down to
> > users 
>
> I find to be particularly antagonistic, but objectively speaking,
> can't we agree that  this is exactly what happened
> with GNOME_DESKTOP_SESSION_ID over the years?  The difference is, a
> sanctioned export is at least sanctioned, as opposed to a deprecated,
> inaccurate or presumptuous technique which is simply guaranteed to
> blow up down the road.

Not sure what you mean here but I think having project-specific
environment variable to control module loading is reasonable. For
example, Qt allows you to set QT_QPA_PLATFORMTHEME=gnome to make Qt
apps look like GNOME apps. Then, users (e.g. on Arch [1]), or even
distributions can set that based on desktop environment (I believe
Fedora does that).

> As an aside -- as a Java developer, I've personally never forced the
> Gtk theme in my applications -- because back when I used KDE the Gtk
> theming wasn't very good.  From the comments above it sounds like the
> mailing list is fairly comfortable stating that the Java Gtk theme
> should simply be default for all Java applications on Linux and I'd
> be happy to begin testing that theory as it may help simplify the
> downstream implementation that OpenJDK chooses to implement.

I agree that when I used Swing-based Java apps in the past, their GTK
UI was egregious. But in my exprerience, the Metal or Motif or whatever
UI was equally bad UX-wise and looking even uglier. I have heard JavaFX
improved the UX situation a lot, though I have not seen any app using
that myself.

[1]: 
https://wiki.archlinux.org/index.php/Uniform_look_for_Qt_and_GTK_applications#QGnomePlatform