Hi,
GNOME 3.34.6 is now available. This is our second "oldstable" release,
intended to benefit distributions that have not yet upgraded to GNOME
3.36, and also flatpak applications that are still using the 3.34
runtime.
If you want to compile GNOME 3.34.6, you can use the official
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
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:
-
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
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
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
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
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
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
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
>
> 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:
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
>
> 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
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
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
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
> 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
> 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
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
> 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
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.
21 matches
Mail list logo
