Re: How to detect a gtk desktop programmatically
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: GJS Docs now Hosted on gnome.org
On Mon, 22 Jul 2019 at 12:21:32 +0300, Anastasios Lisgaras via desktop-devel-list wrote: > I have tried these commands ( on my system > - Debian GNU/Linux 9.9 (stretch), GNOME Shell 3.22.3 - ) and I do not > get any results : > ``` > gjs -v > Failed to open file '-v': No such file or directory > ``` [etc.] > Maybe I need to install some extra package on my system? In Debian, the gjs command-line tool is in the gjs package. If you are running Debian 9.x then you have gjs 1.46.0, which uses mozjs 24. This is rather old - Debian 9 'stretch' was released 2 years ago, and Debian 10 'buster' (with gjs 1.54.x and GNOME 3.30.x) is the latest stable release. I don't think it's going to be straightforward to contribute to upstream GNOME projects from a Debian 9 base. smcv ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deprecating nautilus-sendto
On Wed, 27 Feb 2019 at 13:56:10 +0100, Bastien Nocera wrote: > You could but I would not recommend using xdg-email if your application > will be used outside of a Flatpak because it will end up running this > code: > https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-email.in > which might, or might not work. It's brittle and ugly. Would it be useful to have a non-Flatpak-specific name for Flatpak's portal-friendly reimplementation of xdg-email, and install it on host systems, not just in Flatpak containers? Or to have some sort of non-command-based API for creating an email that can do all the things flatpak-xdg-utils can, perhaps in GIO? (Vaguely precedent: I've packaged flatpak-xdg-utils for Debian 10, to make it more straightforward to build Flatpak runtimes out of Debian 10+ packages. At the moment the flatpak-xdg-utils tools are installed into /usr/libexec rather than onto the PATH, and containers that want them are expected to create their own symlinks, but there's no reason there couldn't be a symlink at /usr/bin/xdg-desktop-portal-email or something.) smcv ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 2 support in GNOME build tools
On Thu, 12 Jul 2018 at 09:29:26 +0200, Christoph Reiter via desktop-devel-list wrote: > we currently do support Python 2 and 3 for things like gobject-introspection > and glib scripts etc. and while I don't see any problem with continuing that > support I'd like to know why we still need to support Python 2 there. i.e. > What needs to happen so that Python 3 support is enough for everyone? Slow-releasing/stable/"enterprise" distributions like RHEL, Debian, Ubuntu LTS and SLED are the usual sticking point for dependency versions. My understanding is that the main blocker for using Python 3 is that RHEL/CentOS 7 doesn't have it built-in, only as part of a secondary "software collection"? For what it's worth, requiring Python 3 would be no problem from Debian's perspective, as long as it isn't assumed to be /usr/bin/python: for compatibility with historical scripts, if /usr/bin/python exists then it is always Python 2, while Python 3 is available at /usr/bin/python3 if installed. Using Python 3 for all programs that can work in either version is recommended, and in particular we've used Python 3 for the GLib and GObject-Introspection build tools since Debian 9 'stretch' (2017). We don't normally backport the latest GNOME versions to stable releases anyway; but if we do, the latest stable release (Debian 9 'stretch') has Python 3.5 as its supported Python 3 version, and the one before that (Debian 8 'jessie', 2015) had 3.4. Ubuntu is in about the same situation as Debian, with new LTS releases every 2 years, although a year out of phase with Debian (the most recent LTS releases were in 2018 and 2016 and have contemporary Python 3 versions). smcv ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
