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 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:

https://mail.openjdk.java.net/pipermail/swing-dev/2020-August/010620.html

- tres.finocchi...@gmail.com


On Thu, Apr 30, 2020 at 12:40 PM Emmanuele Bassi  wrote:

> On Thu, 30 Apr 2020 at 17:23, Michael Catanzaro 
> 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.
>
> Ciao,
>  Emmanuele
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Emmanuele Bassi via desktop-devel-list 
On Thu, 30 Apr 2020 at 17:23, Michael Catanzaro 
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.

Ciao,
 Emmanuele

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Michael Catanzaro 
On Wed, Apr 29, 2020 at 8:16 pm, Tres Finocchiaro via 
desktop-devel-list  wrote:
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.


Well it sounds like everyone here agrees it's the best choice 
everywhere today. If you had a Qt theme, you would want to prefer that 
when running on KDE or LXQt, and use GTK everywhere else. You would 
want to detect those two desktops using $XDG_CURRENT_DESKTOP. But you 
don't have a Qt theme, so best use GTK everywhere and you don't need to 
bother with any environment variables. Simple.


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.



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Michael Catanzaro 
On Thu, Apr 30, 2020 at 2:33 pm, Simon McVittie via desktop-devel-list 
 wrote:

Debian's gnome-session package carries a patch to revert that commit,
unfortunately. We'd like to stop doing that, but as you say, there are
at least 225 instances of packages doing it wrong.


Only way to guarantee those packages are never fixed is to keep the 
patch forever. *shrug*



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Tres Finocchiaro via desktop-devel-list 
Simon,

Thanks kindly for your detailed write up, especially the details including
"Gtk everywhere" examples like Firefox, Libreoffice as well as reasons
around the XDG_CURRENT_DESKTOP values/usage.

Interestingly, apps like IntelliJ have ditched themes like Metal/Win32/Gtk
in favor of their own, but maintaining a custom Look is and
undertaking that's unreasonable for the vast majority of Java developers.

I'll begin unit-testing the Gtk theming across various Unix/Linux desktops
-- especially those that are not Gtk-based -- and see how well it works.


- tres.finocchi...@gmail.com


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]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 detection of a Gtk-desktop (such as the mail
> launcher to
> > prefer Evolution to KMail, etc).
>
> Debian's gnome-session package carries a patch to revert that commit,
> unfortunately. We'd like to stop doing that, but as you say, there are
> at least 225 instances of packages doing it wrong.
>
> However, with or without that patch, anything that is looking at
> the deprecated GNOME_DESKTOP_SESSION_ID and expecting its absence or
> presence to indicate "non-GTK-based desktop" vs. "GTK-based desktop"
> is certainly a bug - not just because newer GNOME no longer sets
> GNOME_DESKTOP_SESSION_ID, but also because there are several GTK-based
> desktops that are not GNOME.
>
> LXDE (before Qt) and XFCE are examples of desktop environments that you
> would probably consider to be "GTK-based", but are not GNOME (not even
> forked or derived from GNOME - they are their own thing, only sharing
> lower-level libraries like GLib and GTK). They set XDG_CURRENT_DESKTOP to
> something that doesn't mention GNOME, and they don't set
> GNOME_DESKTOP_SESSION_ID, because they are not GNOME, and claiming to
> be GNOME would be inappropriate.
>
> MATE, Cinnamon and Deepin are examples of desktop environments based on
> a fork of an older version of GNOME, but which are not GNOME *any more*;
> again, they don't set XDG_CURRENT_DESKTOP to GNOME or anything containing
> GNOME, because they are their own independent desktop environments.
>
> I would recommend that Java GUI apps running on Linux (and probably
> all Unix platforms) should use whichever "look and feel" is considered
> to be high-quality and doesn't look hugely out-of-place. If the GTK
> "look and feel" is considered high-quality, it should probably be used
> everywhere. If it's considered low-quality (lots of bugs or missing
> functionality or whatever), then it would likely be better to use one
> that *is* high-quality, even if it doesn't visually resemble other apps
> on the desktop.
>
> Firefox and Libreoffice use GTK everywhere. If it's good enough for them,
> it's likely also good enough for Java.
>
> smcv
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Simon McVittie via desktop-devel-list 
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]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 detection of a Gtk-desktop (such as the mail launcher to
> prefer Evolution to KMail, etc).

Debian's gnome-session package carries a patch to revert that commit,
unfortunately. We'd like to stop doing that, but as you say, there are
at least 225 instances of packages doing it wrong.

However, with or without that patch, anything that is looking at
the deprecated GNOME_DESKTOP_SESSION_ID and expecting its absence or
presence to indicate "non-GTK-based desktop" vs. "GTK-based desktop"
is certainly a bug - not just because newer GNOME no longer sets
GNOME_DESKTOP_SESSION_ID, but also because there are several GTK-based
desktops that are not GNOME.

LXDE (before Qt) and XFCE are examples of desktop environments that you
would probably consider to be "GTK-based", but are not GNOME (not even
forked or derived from GNOME - they are their own thing, only sharing
lower-level libraries like GLib and GTK). They set XDG_CURRENT_DESKTOP to
something that doesn't mention GNOME, and they don't set
GNOME_DESKTOP_SESSION_ID, because they are not GNOME, and claiming to
be GNOME would be inappropriate.

MATE, Cinnamon and Deepin are examples of desktop environments based on
a fork of an older version of GNOME, but which are not GNOME *any more*;
again, they don't set XDG_CURRENT_DESKTOP to GNOME or anything containing
GNOME, because they are their own independent desktop environments.

I would recommend that Java GUI apps running on Linux (and probably
all Unix platforms) should use whichever "look and feel" is considered
to be high-quality and doesn't look hugely out-of-place. If the GTK
"look and feel" is considered high-quality, it should probably be used
everywhere. If it's considered low-quality (lots of bugs or missing
functionality or whatever), then it would likely be better to use one
that *is* high-quality, even if it doesn't visually resemble other apps
on the desktop.

Firefox and Libreoffice use GTK everywhere. If it's good enough for them,
it's likely also good enough for Java.

smcv
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-30 Thread Benjamin Berg 
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 indicated by the
> Debian search results in the commit that removed this flag -- were in
> the hundreds.

Which does not prove anything. Much of those hits will date back to
code that was written way over ten years ago. When GTK might have not
been as good and–more importantly–other desktops may not have
integrated as well with GTK.

So, yes, people have checked that in the past and it probably was a
deliberate choice back then. For various reasons, I would expect that
"Metal" would have generally been considered better overall. And GTK
probably ended up looking really bad in some cases because 1) the
default theme used to be ugly and 2) other desktops did not integrate
as well.

None of these reasons are true these days. GTK integration is good
across various desktops. "Metal" is probably less modern look wise than
a default ("unthemed") GTK is.

I agree with Ray. With the selection you have, just always choose GTK
on Linux. I truly expect it is the best choice on all desktops a user
might choose on Linux.

> The ability to detect a Gtk-based desktop seems like a perfectly
> valid question.

You are looking for magic that simply does not exist. Just always
GTKLookAndFeel and you will most likely have the best results across
the board.

Benjamin

> On Wed, Apr 29, 2020 at 3:47 PM Ray Strode 
> wrote:
> > Hi,
> > 
> > > So, with the removal of this GNOME_DESKTOP_SESSION_ID variable,
> > how should OpenJDK -- moving forward -- detect a Gtk-based desktop?
> > 
> > So as I understand it, the choices for look and feel are:
> > 
> >  WindowsLookAndFeel, GTKLookAndFeel, AquaLookAndFeel,
> > MotifLookAndFeel, and MetalLookAndFeel
> > 
> > Of those choices, GTKLookAndFeel is the best answer for any linux
> > desktop I think.  KDE configures gtk to look nice on KDE, and the
> > rest
> > of the
> > desktops use GTK or at least look good with GTK.  Defaulting to
> > Metal
> > means looking bad on almost every desktop.
> > 
> > Or can you think of a common desktop choice where GTK look and feel
> > isn't the best option of the available ones?
> > 
> > I think the logic should just be "if running linux, pick gtk".  You
> > shouldn't need to check any environment variables, imo.
> > 
> > --Ray
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 up to version 14 now.
Java 8,9,10 are EOL and 12,13,14 aren't LTS.  Personally, I file bugs
upstream against 11, since it's LTS.  With exception the work by JetBrains,
Desktop integration has mostly the same since Java 6, so these types of
bugs are going to crop up.

As an OpenJDK community member, I find it my civic duty to obtain as much
information as possible to aid in the fixing of these bugs, improving the
experience for Java and Linux alike.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread jtojnar--- via desktop-devel-list 
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


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 technology that desktop is
> using


Ubuntu 18.04 only returns "x11" for that value.

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.

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.

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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Michael Biebl via desktop-devel-list 
Am Do., 30. Apr. 2020 um 00:32 Uhr schrieb Zander Brown :
>
> That's an unfortunate truth which is why I was hoping for an alternative way 
> to detect this.
> At time of writing this, Ubuntu's the only one I've found modifying 
> XDG_CURRENT_DESKTOP and keep something indicative of Gtk inside e.g. 
> (ubuntu:GNOME).
>
>
> Nothing about "ubuntu:GNOME" is "indicative of Gtk", it's stating the fact 
> your running Ubuntu's modified GNOME session.
>
> XDG_CURRENT_DESKTOP is supposed to indicate just that: the current desktop 
> environment
>
> Not some insight into whatever technology that desktop is using - other 
> variables like XDG_SESSION_TYPE do that
>
> Really there is 3 approaches here:
>
> 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
> Maintain a map of know names in OpenJDK itself
> Assume all Linux based platforms use Gtk
>
>
> When your trying to choose between Windows, GTK, Aqua, Motif & Metal the best 
> choice would seem to be 3
>
> When KDELookAndFeel becomes a thing you can worry about detecting KDE or 
> LXQt, currently this is a rather academic exercise

I have no idea how the Gtk LaF is implemented in Swing and if it needs
any Gtk system libraries.
Wonder how it would behave if you run a KDE or Qt based desktop and no
Gtk libraries are installed,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Zander Brown 
> That's an unfortunate truth which is why I was hoping for an alternative way
> to detect this.
> At time of writing this, Ubuntu's the only one I've found modifying
> XDG_CURRENT_DESKTOP and keep something indicative of Gtk inside  e.g.
> (ubuntu:GNOME).

Nothing about "ubuntu:GNOME" is "indicative of Gtk", it's stating the fact your
running Ubuntu's modified GNOME session.

XDG_CURRENT_DESKTOP is supposed to indicate just that: the current desktop
environment

Not some insight into whatever technology that desktop is using - other
variables like XDG_SESSION_TYPE do that

Really there is 3 approaches here:
   1. 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
   2. Maintain a map of know names in OpenJDK itself
   3. Assume all Linux based platforms use Gtk

When your trying to choose between Windows, GTK, Aqua, Motif & Metal the best
choice would seem to be 3

When KDELookAndFeel becomes a thing you can worry about detecting KDE or LXQt,
currently this is a rather academic exercise




signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 someone decides to standardize it and sends merge requests
> to all major desktop environments, it will still take ages before it is
> widely available.


That's an unfortunate truth which is why I was hoping for an alternative
way to detect this.

At time of writing this, Ubuntu's the only one I've found modifying
XDG_CURRENT_DESKTOP and keep something indicative of Gtk inside e.g.
(ubuntu:GNOME).   I assume that's because they've ditched Unity and are
finally back to using Gnome, but in a customized form; whereas the others
are simply Gtk-based and use their own name.

It would be nice to have a consensus on a long-term supported property that
exposes the presence of a running Gtk-based desktop to application
developers.  Even if such a value provides presumptuous information, it's
information, which is valuable.

If this consensus were agreed upon, the 80/20 stop-gaps of the world would
become the new "deprecated; a path to detection would be sanctioned,
instead of a mispurposed one.



- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 5:40 PM  wrote:

> On Wed, 2020-04-29 at 17:03 -0400, Tres Finocchiaro wrote:
> > > The best you can do is have a mapping of common DEs to their
> > > preferred
> > > toolkits
> >
> > This would mean each Gtk-based DE will require a patch to OpenJDK,
> > which is unsustainable.
>
> I agree that this is inconvenient but in the absence of a better
> option, you either make a list, or come up with some heuristic.
>
> > > There is no such thing as GTK desktop
> >
> > Wikipedia has its own category:
> > https://en.wikipedia.org/wiki/Category:Desktop_environments_based_on_GTK
>
> But that is only what people see. Desktops do not care about toolkits,
> only thing that matters is that the app can connect to the desktop’s
> display server.
>
> And while it would be possible to make desktops record the consensus on
> the preference of toolkits in their respective communities and expose
> it via some API like an environment variable, someone would need to
> come up with the API and then convince all desktop environments it is
> something they should implement.
>
> Given the limited usefulness of such API, I do not see anyone spending
> time on that effort.
>
> And even if someone decides to standardize it and sends merge requests
> to all major desktop environments, it will still take ages before it is
> widely available.
>
> > In regards to Gtk2 versus Gtk3 binding, those issues haven't changed
> > as results of this missing variable.
>
> How do they decide if they should use GTK 3 or GTK 2?
>
> > I'm not sure I understand the reluctance to provide such information.
>
> I do not think anyone is opposed to that but I doubt anyone will
> consider it a priority. Especially since the intersection of
> toolkits supported by AWT and toolkits prefered can be emulated using
> much simpler algorithm.
>
> preferred | GTK | Qt  | EFL
> --|-|-|-|
> has GTK   | GTK | GTK | GTK |
> no GTK|error|Motif|Motif|
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Ty Young via desktop-devel-list 


On 4/29/20 4:17 PM, Tres Finocchiaro via desktop-devel-list wrote:
I'd like to disclaim that since I'm not an OpenJDK developer, the 
upstream decision may very-well be to attempt to load Gtk when the 
system is anything other than Windows or MacOS.  I can't speak on 
behalf of the end-strategy of OpenJDK and I do not represent them or 
their solution to this problem.


That said, for reasons mentioned above as well as evidence in Gnome's 
codebase, Debian's codebase and Java's codebase, I observe a valid 
use-case for asking if the desktop environment is Gtk-based.  To deny 
that suggests that solutions which check are invalid, or contain no 
value and I believe this perspective to be short-sighted as 
admittingly my sight is as well.


-Tres

- tres.finocchi...@gmail.com 




Not a Gnome/GTK/OpenJDK developer but it sounds like you're asking for 
the wrong thing. What you need is standard way of getting a list of UI 
toolkits(GTK/QT/whatever) installed. It doesn't matter what the desktop 
is, only that GTK is installed.



Good luck with that, by the by. Even if you could somehow get 
Gnome/KDE/whomever to agree to implement such a thing(ha!), distros will 
find a way to break it somehow.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list 
I'd like to disclaim that since I'm not an OpenJDK developer, the upstream
decision may very-well be to attempt to load Gtk when the system is
anything other than Windows or MacOS.  I can't speak on behalf of the
end-strategy of OpenJDK and I do not represent them or their solution to
this problem.

That said, for reasons mentioned above as well as evidence in Gnome's
codebase, Debian's codebase and Java's codebase, I observe a valid use-case
for asking if the desktop environment is Gtk-based.  To deny that suggests
that solutions which check are invalid, or contain no value and I believe
this perspective to be short-sighted as admittingly my sight is as well.

-Tres

- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 5:03 PM Tres Finocchiaro 
wrote:

> The best you can do is have a mapping of common DEs to their preferred
>> toolkits
>
>
> This would mean each Gtk-based DE will require a patch to OpenJDK, which
> is unsustainable.
>
> There is no such thing as GTK desktop
>
>
> Wikipedia has its own category:
> https://en.wikipedia.org/wiki/Category:Desktop_environments_based_on_GTK
>
> In regards to Gtk2 versus Gtk3 binding, those issues haven't changed as
> results of this missing variable.  To request an environmental variable
> which exposes this is a reasonable request.  I'm not sure I understand the
> reluctance to provide such information.
>
> - 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 use-cases for this -- as indicated by the
>> > Debian search results in the commit that removed this flag -- were in
>> > the hundreds.
>>
>> There is no such thing as GTK desktop. Some desktops like GNOME or
>> Pantheon use GTK 3 a lot, others like KDE or LXQt use predominantly Qt,
>> but that is more of a social custom than technical feature that can be
>> detected.
>>
>> For lot of environments it is not even clear cut as that: Xfce only
>> just recently managed to migrate most of its apps to GTK 3 but some
>> still remain on GTK 2, Deepin has weird mix of GTK, Qt and other
>> things, Enligthenment uses its own EFL… And that is not mentioning the
>> tens of “light” WMs/DMs like Openbox, Sway or XMonad that have no
>> toolkit at all and rely purely on user’s preferences.
>>
>> The best you can do is have a mapping of common DEs to their preferred
>> toolkits but, as Ray mentions, given that you only support GTK and
>> ¿Motif?, all modern Linux DEs (e.g. those that set the
>> `XDG_CURRENT_DESKTOP` variable to something) will prefer GTK when
>> available. Though it is good idea to add an environment variable like
>> `JAVA_AWT_TOOLKIT` so that people can switch to Motif if they for some
>> reason do want to use that.
>>
>>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Tres Finocchiaro via desktop-devel-list 
>
> The best you can do is have a mapping of common DEs to their preferred
> toolkits


This would mean each Gtk-based DE will require a patch to OpenJDK, which is
unsustainable.

There is no such thing as GTK desktop


Wikipedia has its own category:
https://en.wikipedia.org/wiki/Category:Desktop_environments_based_on_GTK

In regards to Gtk2 versus Gtk3 binding, those issues haven't changed as
results of this missing variable.  To request an environmental variable
which exposes this is a reasonable request.  I'm not sure I understand the
reluctance to provide such information.

- 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 use-cases for this -- as indicated by the
> > Debian search results in the commit that removed this flag -- were in
> > the hundreds.
>
> There is no such thing as GTK desktop. Some desktops like GNOME or
> Pantheon use GTK 3 a lot, others like KDE or LXQt use predominantly Qt,
> but that is more of a social custom than technical feature that can be
> detected.
>
> For lot of environments it is not even clear cut as that: Xfce only
> just recently managed to migrate most of its apps to GTK 3 but some
> still remain on GTK 2, Deepin has weird mix of GTK, Qt and other
> things, Enligthenment uses its own EFL… And that is not mentioning the
> tens of “light” WMs/DMs like Openbox, Sway or XMonad that have no
> toolkit at all and rely purely on user’s preferences.
>
> The best you can do is have a mapping of common DEs to their preferred
> toolkits but, as Ray mentions, given that you only support GTK and
> ¿Motif?, all modern Linux DEs (e.g. those that set the
> `XDG_CURRENT_DESKTOP` variable to something) will prefer GTK when
> available. Though it is good idea to add an environment variable like
> `JAVA_AWT_TOOLKIT` so that people can switch to Motif if they for some
> reason do want to use that.
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread jtojnar--- via desktop-devel-list 
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 indicated by the
> Debian search results in the commit that removed this flag -- were in
> the hundreds.

There is no such thing as GTK desktop. Some desktops like GNOME or
Pantheon use GTK 3 a lot, others like KDE or LXQt use predominantly Qt,
but that is more of a social custom than technical feature that can be
detected.

For lot of environments it is not even clear cut as that: Xfce only
just recently managed to migrate most of its apps to GTK 3 but some
still remain on GTK 2, Deepin has weird mix of GTK, Qt and other
things, Enligthenment uses its own EFL… And that is not mentioning the
tens of “light” WMs/DMs like Openbox, Sway or XMonad that have no
toolkit at all and rely purely on user’s preferences.

The best you can do is have a mapping of common DEs to their preferred
toolkits but, as Ray mentions, given that you only support GTK and
¿Motif?, all modern Linux DEs (e.g. those that set the
`XDG_CURRENT_DESKTOP` variable to something) will prefer GTK when
available. Though it is good idea to add an environment variable like
`JAVA_AWT_TOOLKIT` so that people can switch to Motif if they for some
reason do want to use that.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

-Tres


- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 3:47 PM Ray Strode  wrote:

> Hi,
>
> > So, with the removal of this GNOME_DESKTOP_SESSION_ID variable, how
> should OpenJDK -- moving forward -- detect a Gtk-based desktop?
>
> So as I understand it, the choices for look and feel are:
>
>  WindowsLookAndFeel, GTKLookAndFeel, AquaLookAndFeel,
> MotifLookAndFeel, and MetalLookAndFeel
>
> Of those choices, GTKLookAndFeel is the best answer for any linux
> desktop I think.  KDE configures gtk to look nice on KDE, and the rest
> of the
> desktops use GTK or at least look good with GTK.  Defaulting to Metal
> means looking bad on almost every desktop.
>
> Or can you think of a common desktop choice where GTK look and feel
> isn't the best option of the available ones?
>
> I think the logic should just be "if running linux, pick gtk".  You
> shouldn't need to check any environment variables, imo.
>
> --Ray
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Ray Strode via desktop-devel-list 
Hi,

> So, with the removal of this GNOME_DESKTOP_SESSION_ID variable, how should 
> OpenJDK -- moving forward -- detect a Gtk-based desktop?

So as I understand it, the choices for look and feel are:

 WindowsLookAndFeel, GTKLookAndFeel, AquaLookAndFeel,
MotifLookAndFeel, and MetalLookAndFeel

Of those choices, GTKLookAndFeel is the best answer for any linux
desktop I think.  KDE configures gtk to look nice on KDE, and the rest
of the
desktops use GTK or at least look good with GTK.  Defaulting to Metal
means looking bad on almost every desktop.

Or can you think of a common desktop choice where GTK look and feel
isn't the best option of the available ones?

I think the logic should just be "if running linux, pick gtk".  You
shouldn't need to check any environment variables, imo.

--Ray
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 comparison which will ultimately ignore desktops which
override this value.  The Gnome commit seems to be in agreement of this, so
I feel a better technique is warranted.  I'm happy to hear arguments to the
contrary.

- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 3:32 PM Tres Finocchiaro 
wrote:

> 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 which sets
> it in Gnome3 kindly leaves it alone.
>
> Ubuntu it kind enough to append "ubuntu:GNOME", so the above line works,
> but this doesn't seem to be a universally adopted standard.
>
> It seems it would be of great service to expose something.  I'm not sure I
> agree that an environment variable is a bad way to do this, it's a variable
> which describes the environment.  It seems just about perfect. ;)
>
>
> - tres.finocchi...@gmail.com
>
>
> On Wed, Apr 29, 2020 at 3:27 PM Tres Finocchiaro <
> tres.finocchi...@gmail.com> wrote:
>
>> 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 detection of a Gtk-desktop (such as the mail
>> launcher to prefer Evolution to KMail, etc).
>>
>> I'll browse the Debian code to see how they've worked around this issue
>> since.
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 which sets it in
Gnome3 kindly leaves it alone.

Ubuntu it kind enough to append "ubuntu:GNOME", so the above line works,
but this doesn't seem to be a universally adopted standard.

It seems it would be of great service to expose something.  I'm not sure I
agree that an environment variable is a bad way to do this, it's a variable
which describes the environment.  It seems just about perfect. ;)


- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 3:27 PM Tres Finocchiaro 
wrote:

> 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 detection of a Gtk-desktop (such as the mail
> launcher to prefer Evolution to KMail, etc).
>
> I'll browse the Debian code to see how they've worked around this issue
> since.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 detection of a Gtk-desktop (such as the mail
launcher to prefer Evolution to KMail, etc).

I'll browse the Debian code to see how they've worked around this issue
since.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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:

- Fedora 27: Java apps that request system's theme look fine, properly use
Gtk3 theme.
- Fedora 32: Java apps that request system's theme don't look fine,
fallback to the Java Swing theme.

The issue is larger than Fedora of course.  I had similar issues on other
Desktops, which I've outlined in detail here:

https://github.com/AdoptOpenJDK/openjdk-support/issues/94#issuecomment-621346178

Downstream, any Java developer is going to look to OpenJDK to patch this,
but I'm asking here first, since the next step is reporting directly to
OpenJDK's upstream tracker and if I have a solution from the Gnome team,
it'll be resolved much quicker.

- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 3:09 PM Tres Finocchiaro 
wrote:

> 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 about how to know
> the desktop is running to begin with.  Any insight is greatly appreciated.
>
>
> - tres.finocchi...@gmail.com
>
>
> On Wed, Apr 29, 2020 at 3:03 PM Tres Finocchiaro <
> tres.finocchi...@gmail.com> wrote:
>
>> 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 preflight which is leveraged to
>> avoid loading the libraries unintentionally.
>>
>> I think what OpenJDK is trying to avoid is blindly loading a library
>> that's on the system without knowing if it's actually in-use.  This
>> variable -- albeit deprecated -- was a reliable way to know that.
>>
>> Here it checks to see if Gnome is running:
>>
>> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L100
>>
>> Here, it configures the look and feel:
>>
>> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/share/classes/javax/swing/UIManager.java#L665
>>
>> And deeper into the native calls, it interacts with Gtk libraries:
>>
>> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/native/libawt_xawt/awt/awt_UNIXToolkit.c#L53
>>
>> So although I can't answer the specific theming questions, I can confirm
>> the theme seems to apply correctly on systems which utilize it.  It's less
>> of a matter of how to detect the theme and more of a matter of how to
>> detect that the desktop environment offers a Gtk theme to begin with.
>>
>> Albeit deprecated and clunky, GNOME_DESKTOP_SESSION_ID seemed to have
>> been the way Java's known this historically and removal of it requires a
>> replacement of which I'm hoping to gain knowledge of.
>>
>> - tres.finocchi...@gmail.com
>>
>>
>> On Wed, Apr 29, 2020 at 1:37 PM Matthias Clasen <
>> matthias.cla...@gmail.com> wrote:
>>
>>>
>>> Hey Tres,
>>>
>>> in my opinion, environment variables are about the worst possible option
>>> for this sort of thing.
>>>
>>> If you are linking against GTK, the easiest way is to just ask GTK
>>> itself if you need to know
>>> the theme name:
>>>
>>> g_object_get (gtk_settings_get_defautt (), "gtk-theme-name", ,
>>> NULL);
>>>
>>> But I am not sure that the theme name is really needed. What information
>>> are you looking for
>>> exactly ? And what decision are you going to make based on it ?
>>>
>>>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 about how to know the
desktop is running to begin with.  Any insight is greatly appreciated.


- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 3:03 PM Tres Finocchiaro 
wrote:

> 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 preflight which is leveraged to
> avoid loading the libraries unintentionally.
>
> I think what OpenJDK is trying to avoid is blindly loading a library
> that's on the system without knowing if it's actually in-use.  This
> variable -- albeit deprecated -- was a reliable way to know that.
>
> Here it checks to see if Gnome is running:
>
> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L100
>
> Here, it configures the look and feel:
>
> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/share/classes/javax/swing/UIManager.java#L665
>
> And deeper into the native calls, it interacts with Gtk libraries:
>
> https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/native/libawt_xawt/awt/awt_UNIXToolkit.c#L53
>
> So although I can't answer the specific theming questions, I can confirm
> the theme seems to apply correctly on systems which utilize it.  It's less
> of a matter of how to detect the theme and more of a matter of how to
> detect that the desktop environment offers a Gtk theme to begin with.
>
> Albeit deprecated and clunky, GNOME_DESKTOP_SESSION_ID seemed to have been
> the way Java's known this historically and removal of it requires a
> replacement of which I'm hoping to gain knowledge of.
>
> - tres.finocchi...@gmail.com
>
>
> On Wed, Apr 29, 2020 at 1:37 PM Matthias Clasen 
> wrote:
>
>>
>> Hey Tres,
>>
>> in my opinion, environment variables are about the worst possible option
>> for this sort of thing.
>>
>> If you are linking against GTK, the easiest way is to just ask GTK itself
>> if you need to know
>> the theme name:
>>
>> g_object_get (gtk_settings_get_defautt (), "gtk-theme-name", ,
>> NULL);
>>
>> But I am not sure that the theme name is really needed. What information
>> are you looking for
>> exactly ? And what decision are you going to make based on it ?
>>
>>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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 preflight which is leveraged to
avoid loading the libraries unintentionally.

I think what OpenJDK is trying to avoid is blindly loading a library that's
on the system without knowing if it's actually in-use.  This variable --
albeit deprecated -- was a reliable way to know that.

Here it checks to see if Gnome is running:
https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L100

Here, it configures the look and feel:
https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/share/classes/javax/swing/UIManager.java#L665

And deeper into the native calls, it interacts with Gtk libraries:
https://github.com/AdoptOpenJDK/openjdk-jdk/blob/634c676e6c145c936b460debaa95d0b6cfa61ae2/src/java.desktop/unix/native/libawt_xawt/awt/awt_UNIXToolkit.c#L53

So although I can't answer the specific theming questions, I can confirm
the theme seems to apply correctly on systems which utilize it.  It's less
of a matter of how to detect the theme and more of a matter of how to
detect that the desktop environment offers a Gtk theme to begin with.

Albeit deprecated and clunky, GNOME_DESKTOP_SESSION_ID seemed to have been
the way Java's known this historically and removal of it requires a
replacement of which I'm hoping to gain knowledge of.

- tres.finocchi...@gmail.com


On Wed, Apr 29, 2020 at 1:37 PM Matthias Clasen 
wrote:

>
> Hey Tres,
>
> in my opinion, environment variables are about the worst possible option
> for this sort of thing.
>
> If you are linking against GTK, the easiest way is to just ask GTK itself
> if you need to know
> the theme name:
>
> g_object_get (gtk_settings_get_defautt (), "gtk-theme-name", , NULL);
>
> But I am not sure that the theme name is really needed. What information
> are you looking for
> exactly ? And what decision are you going to make based on it ?
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How to detect a gtk desktop programmatically

2020-04-29 Thread Matthias Clasen via desktop-devel-list 
Hey Tres,

in my opinion, environment variables are about the worst possible option
for this sort of thing.

If you are linking against GTK, the easiest way is to just ask GTK itself
if you need to know
the theme name:

g_object_get (gtk_settings_get_defautt (), "gtk-theme-name", , NULL);

But I am not sure that the theme name is really needed. What information
are you looking for
exactly ? And what decision are you going to make based on it ?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list