Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
Matthias, Thanks for the detailed response. Please accept my lack of knowledge on the subject as I'm neither an OpenJDK developer nor a C developer, (I develop using Java, so information is to benefit the bug report against OpenJDK). That said... It appears the environment variable is a

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
Also, to help explain scope, all Java applications that use the Gtk theme are affected with the removal of this environment variable. I'm not issuing blame, it's been deprecated for a very long time now, but when OpenJDK patches this they'll need a new way of detecting that Gnome is running: -

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
Just to confirm, OpenJDK is currently leveraging "gtk-theme-name" as you've indicated: https://github.com/AdoptOpenJDK/openjdk-jdk/blob/858ec1c5fad02242b7452099f3d5789e55a79057/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c#L725 I believe question is less about which theme and more

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
It appears a lot of Debian code still relies on this missing value. Some have switched to this technique: os.getenv("XDG_CURRENT_DESKTOP", "").endswith("GNOME") ... however for reasons mentioned earlier, this will fail on XFCE, Pantheon and many others as they set this value, so the C-code

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
Here's a Gnome-project commit making similar assumptions: https://gitlab.gnome.org/GNOME/glib-networking/commit/89c45b82b85daef0f1e679dbd15a9c7c893deb17#d53b9ec213c7c4dd230c7ad15ccf62b542a79279_316_316 As indicated in previous emails, XDG_CURRENT_DESKTOP is less reliable as it relies on string

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
For reference, the commit which introduced this change: https://gitlab.gnome.org/GNOME/gnome-session/commit/00e0e6226371d53f651cc881e74c0543192c94a8#5b3005b925ed5c2612a9604ad3c756b1f9472165 Note, at the time of committing that, Debian still had 225 instances of the OS relying on this for

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
I'm asking how to detect a Gtk desktop. An answer that says "always' isn't really correct. The use-cases for this -- as indicated by the Debian search results in the commit that removed this flag -- were in the hundreds. The ability to detect a Gtk-based desktop seems like a perfectly valid

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
formation. - tres.finocchi...@gmail.com On Wed, Apr 29, 2020 at 4:46 PM wrote: > On Wed, 2020-04-29 at 15:59 -0400, Tres Finocchiaro via desktop-devel- > list wrote: > > I'm asking how to detect a Gtk desktop. An answer that says "always' > > isn't really correct. The us

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
> > How do they decide if they should use GTK 3 or GTK 2? I had to research this, but apparently they made a cut-over at some point. https://bugs.openjdk.java.net/browse/JDK-8198649 (not attempting to minimize the problem, just wanted to isolate it from what we're discussing) And even if

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
2020 at 4:46 PM wrote: > >> On Wed, 2020-04-29 at 15:59 -0400, Tres Finocchiaro via desktop-devel- >> list wrote: >> > I'm asking how to detect a Gtk desktop. An answer that says "always' >> > isn't really correct. The use-cases for this -- as in

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Tres Finocchiaro via desktop-devel-list
m On Thu, Apr 30, 2020 at 9:40 AM Simon McVittie via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > On Wed, 29 Apr 2020 at 15:27:02 -0400, Tres Finocchiaro via > desktop-devel-list wrote: > > For reference, the commit which introduced this change: > > [1]ht

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
> Wonder how it would behave if you run a KDE or Qt based desktop and no > Gtk libraries are installed 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. XDG_SESSION_TYPE [offers] insight into whatever

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
> I have heard JavaFX improved the UX situation a lot, though I have not seen any app using that myself. Albeit slightly off-topic, JavaFX was removed from the JDK starting with Java 9, so any UX/UI improvements it brings come with other, larger complications to app developers. Meanwhile Java's

How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list
Hi, I've noticed in recent versions of Gnome, Java stopped honoring the Gtk desktop theme. I haven't found the exact commit that introduced this change, but I suspect the team finally removed the deprecated environmental variable GNOME_DESKTOP_SESSION_ID, which Java has relied on for a long time.

Re: How to detect a gtk desktop programmatically

2020-08-14 Thread Tres Finocchiaro via desktop-devel-list
Just an update, OpenJDK does not agree that forcing the Gtk theme on desktops such as KDE are warranted. Quoting: 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