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
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
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
mailin
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 th
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, b
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
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
>
> 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 u
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 s
> 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 te
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.
> 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 "indicati
>
> 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
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 o
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 abse
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.
>
> 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_
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
>
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
ques
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
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 com
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 whic
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
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:
- Fe
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
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 preflig
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", &theme, NULL);
Bu
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.
28 matches
Mail list logo