Re: How to detect a gtk desktop programmatically

Just an update, OpenJDK does not agree that forcing the Gtk theme on desktops such as KDE are warranted.


The status quo that if it isn't GTK, we use Metal seems like the right
thing to stick with.  There'd be larger changes needed to support GTK if (for example) the
right libraries weren't installed, and who knows what UI defaults would be set to and if
themes would work properly and even then what's the point ? 
All in all safe and simpler to use Metal.

Unfortunately, the patch goes to similar lengths as the aforementioned Debian scripts, checking for the string "gnome" in the XDG_CURRENT_DESKTOP.  I've reached out to the JDK developer to warn them that for distributions such as Pantheon, this solution will fail.

The good news is OpenJDK will look correct on *most* desktops.

Link to the openjdk mailing list conversation:

On Thu, Apr 30, 2020 at 12:40 PM Emmanuele Bassi <ebassi gmail com> wrote:
On Thu, 30 Apr 2020 at 17:23, Michael Catanzaro <mcatanzaro gnome org> wrote:
I would worry about the future, though. I'm skeptical that updating to
GTK 4 will ever be possible (due to the removal of the foreign drawing
API that allows non-GTK apps to render boxes and buttons and such using
the GTK theme). So even if it's the best option today, I don't see much
long-term future here. I'm not sure what the Java community should be
doing, but probably thinking about this early would be better than
waiting until GTK 4 is released and it's too late for major changes.

Slight correction: with GTK4 it's still possible to create render nodes and use them to render CSS state, but you have to handle that state on your own. In practice, this means you won't be able to use GTK API to render stuff that looks like a GTK widget according to the current theme; if you want something that looks like a GtkWidget, you need to use GtkWidget.


[@] ebassi []

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