Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Sun, Jan 14, 2024 at 05:01:43PM +0100, Andrea Bolognani wrote: > On Tue, Jan 09, 2024 at 11:25:50PM +0100, Andrea Bolognani wrote: > > On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > > > It's up to you whether to upstream this part. I would personally say > > > that any reason we give for wanting this change in Debian is probably > > > equally valid as a reason for wanting this change upstream. The line > > > I've been drawing for whether to open bugs like this one is that if a > > > window manager installs into /usr/share/xsessions/, then it's declaring > > > itself to be a (very small) desktop environment, therefore it should do > > > "desktop environment" things like expressing a preference for an > > > xdg-desktop-portal backend. > > > > I'll think about it. Upstream might be reticent to accept such a > > change, so I'll definitely start with the DesktopNames part, which > > shouldn't be controversial, and then possibly follow up with the > > portal part. > > Patches for the DesktopNames part submitted upstream. > > https://github.com/conformal/spectrwm/pull/556 This has been merged upstream. The portals part, which I've kept downstream-only at least for now, is https://salsa.debian.org/debian/spectrwm/-/merge_requests/6 So all that's left is waiting for 3.6 to be released. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Tue, Jan 09, 2024 at 11:25:50PM +0100, Andrea Bolognani wrote: > On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > > It's up to you whether to upstream this part. I would personally say > > that any reason we give for wanting this change in Debian is probably > > equally valid as a reason for wanting this change upstream. The line > > I've been drawing for whether to open bugs like this one is that if a > > window manager installs into /usr/share/xsessions/, then it's declaring > > itself to be a (very small) desktop environment, therefore it should do > > "desktop environment" things like expressing a preference for an > > xdg-desktop-portal backend. > > I'll think about it. Upstream might be reticent to accept such a > change, so I'll definitely start with the DesktopNames part, which > shouldn't be controversial, and then possibly follow up with the > portal part. Patches for the DesktopNames part submitted upstream. https://github.com/conformal/spectrwm/pull/556 -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > On Tue, 09 Jan 2024 at 00:27:41 +0100, Andrea Bolognani wrote: > > Just out of curiosity, is there any advantage to having the trailing > > semicolon in this case? We only have a single item in the list after > > all. > > Yes but only a very small advantage. DesktopNames is a value of type > "strings" (string list) and in the .desktop specification, those are > canonically a list of semicolon-terminated items (unlike e.g. PATH, > which is colon-separated rather than colon-terminated, therefore does > not normally have a trailing colon). My reading of the spec is that > implementations are required to tolerate a missing trailing semicolon, > and a trailing semicolon is only mandatory if the last item is an empty > string, which is not true here; but it seemed best to use a > canonical/consistent representation when giving you a recommendation. Okay, trailing semicolon it is. > > Gtk is probably the most reasonable choice: not only it matches the > > existing default, but it's also somewhat more lightweight in that it > > doesn't drag in a dozen libraries like the KDE implementation does. > > > > Honestly, neither quite fits with spectrwm's aesthetic... We'd > > probably want an old school, unthemed Gtk 2 implementation or > > something like that. Shame it doesn't seem to exist. Oh well :) > > Please don't introduce new GTK 2 software into Debian, even if it's > aesthetically appealing: GTK 2 is dead and will not receive any new > upstream releases, even for critical/security bugs. To be clear, I had no intention of doing that in the first place! I was just wondering out loud which hypothetical implementation would feel the least out of place within spectrwm :) > Apply a flat, > hard-edged, right-angle-cornered theme to a maintained toolkit like > GTK 3 or 4, or a similarly new branch of Qt, if you are looking for a > retrocomputing aesthetic :-) Not a bad suggestion, I might try this just for kicks :) > It's up to you whether to upstream this part. I would personally say > that any reason we give for wanting this change in Debian is probably > equally valid as a reason for wanting this change upstream. The line > I've been drawing for whether to open bugs like this one is that if a > window manager installs into /usr/share/xsessions/, then it's declaring > itself to be a (very small) desktop environment, therefore it should do > "desktop environment" things like expressing a preference for an > xdg-desktop-portal backend. I'll think about it. Upstream might be reticent to accept such a change, so I'll definitely start with the DesktopNames part, which shouldn't be controversial, and then possibly follow up with the portal part. > > I have configured spectrwm to prefer Gtk and > > WindowMaker to prefer KDE, and after using one of the two, logging > > out and switching to the other one doesn't seems to be enough to get > > the other implementation to run: I have to reboot the machine, or at > > the very least kill all user processes even remotely related to the > > desktop portal. > > That's undesired, but also hard to fix. > [...] > > The result is that xdg-desktop-portal continues to run, and its execution > environment still contains the XDG_CURRENT_DESKTOP from the first desktop > environment that you logged into, so as far as it is concerned, nothing has > changed and you still want the first desktop environment's portal backend. Understood. I imagined something along these lines when I noticed that processes would stick around even after closing the session. > Most Debian users choose one desktop environment (per uid) and stick to it, > so this isn't generally a significant problem in practice. Agreed. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Tue, 09 Jan 2024 at 00:27:41 +0100, Andrea Bolognani wrote: > On Fri, Sep 01, 2023 at 12:06:40PM +0100, Simon McVittie wrote: > > DesktopNames=spectrwm; > > Just out of curiosity, is there any advantage to having the trailing > semicolon in this case? We only have a single item in the list after > all. Yes but only a very small advantage. DesktopNames is a value of type "strings" (string list) and in the .desktop specification, those are canonically a list of semicolon-terminated items (unlike e.g. PATH, which is colon-separated rather than colon-terminated, therefore does not normally have a trailing colon). My reading of the spec is that implementations are required to tolerate a missing trailing semicolon, and a trailing semicolon is only mandatory if the last item is an empty string, which is not true here; but it seemed best to use a canonical/consistent representation when giving you a recommendation. If you used a generic parser/serializer like GLib's GKeyFile, it would write out string lists with the trailing semicolon. > > [preferred] > > default=gtk; > > This feels more suitable for a downstream patch, would you agree? > > Gtk is probably the most reasonable choice: not only it matches the > existing default, but it's also somewhat more lightweight in that it > doesn't drag in a dozen libraries like the KDE implementation does. > > Honestly, neither quite fits with spectrwm's aesthetic... We'd > probably want an old school, unthemed Gtk 2 implementation or > something like that. Shame it doesn't seem to exist. Oh well :) Please don't introduce new GTK 2 software into Debian, even if it's aesthetically appealing: GTK 2 is dead and will not receive any new upstream releases, even for critical/security bugs. Apply a flat, hard-edged, right-angle-cornered theme to a maintained toolkit like GTK 3 or 4, or a similarly new branch of Qt, if you are looking for a retrocomputing aesthetic :-) The gtk portal backend is more like a "least-bad" choice than a best choice here: it's enough to make basic/expected functionality for e.g. Flatpak apps possible, and not look completely out-of-place in most desktop environments. Desktop environments are encouraged to provide their own backend if they want to, but I realise that for the long tail of "minor" desktop environments that isn't really realistic. Since I opened this bug report, I've continued to be in discussion with xdg-desktop-portal upstream, and they've accepted a patch that I initially wrote as a Debian-specific thing, to hard-code the gtk backend as a backend of last resort for otherwise-unsupported environments. It will log warnings when it does that, so if you have assessed the available portal backends and decided that gtk is the least-bad one, it's still advantageous to set that explicitly. It's up to you whether to upstream this part. I would personally say that any reason we give for wanting this change in Debian is probably equally valid as a reason for wanting this change upstream. The line I've been drawing for whether to open bugs like this one is that if a window manager installs into /usr/share/xsessions/, then it's declaring itself to be a (very small) desktop environment, therefore it should do "desktop environment" things like expressing a preference for an xdg-desktop-portal backend. > I have configured spectrwm to prefer Gtk and > WindowMaker to prefer KDE, and after using one of the two, logging > out and switching to the other one doesn't seems to be enough to get > the other implementation to run: I have to reboot the machine, or at > the very least kill all user processes even remotely related to the > desktop portal. That's undesired, but also hard to fix. It's a combination of a couple of factors: - Upstream systemd terminates all user processes on logout by default (/etc/systemd/logind.conf [Login] KillUserProcesses=yes), but Debian currently patches it to not do this (KillUserProcesses=no) to avoid disruption for users of screen and tmux. systemd upstream's opinion is that screen and tmux should explicitly register with logind as new sessions so that they can outlive your GUI desktop session, but they do not yet do this, so we have that workaround. - Some desktop environments like GNOME (and I think also KDE Plasma) start up as a `systemd --user` service via graphical-session.target, which means that xdg-desktop-portal.service will automatically be killed on logout even if there are other "lingering" processes; but spectrwm and WindowMaker presumably do not do that, so xdg-desktop-portal is not notified when those desktop sessions end, and will continue to run. The result is that xdg-desktop-portal continues to run, and its execution environment still contains the XDG_CURRENT_DESKTOP from the first desktop environment that you logged into, so as far as it is concerned, nothing has changed and you still want the first desktop environment's portal backend. Most Debian users choose one
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Fri, Sep 01, 2023 at 12:06:40PM +0100, Simon McVittie wrote: > Package: spectrwm > Version: 3.4.1-3 > Severity: normal > User: xdg-desktop-por...@packages.debian.org > Usertags: portals.conf Hi Simon, apologies for taking a while to get back to you. I'm actively looking into this now. > Suggested fix > = > > Add a sequence of semicolon-separated desktop environment names to > /usr/share/xsessions/spectrwm.desktop, most likely just "spectrwm": > > DesktopNames=spectrwm; This makes perfect sense, and would also be totally suitable for upstream, where spectrwm.desktop already lives. I'll prepare a patch and propose it there. Just out of curiosity, is there any advantage to having the trailing semicolon in this case? We only have a single item in the list after all. > And then create a /usr/share/xdg-desktop-portal/spectrwm-portals.conf > with whatever portal backends are desired for a spectrwm session, > for example perhaps this: > > [preferred] > default=gtk; This feels more suitable for a downstream patch, would you agree? Gtk is probably the most reasonable choice: not only it matches the existing default, but it's also somewhat more lightweight in that it doesn't drag in a dozen libraries like the KDE implementation does. Honestly, neither quite fits with spectrwm's aesthetic... We'd probably want an old school, unthemed Gtk 2 implementation or something like that. Shame it doesn't seem to exist. Oh well :) By the way, while playing around with this to understand how the various pieces fit together I noticed that there seems to be a significant amount of caching going on. By this I mean that I have configured spectrwm to prefer Gtk and WindowMaker to prefer KDE, and after using one of the two, logging out and switching to the other one doesn't seems to be enough to get the other implementation to run: I have to reboot the machine, or at the very least kill all user processes even remotely related to the desktop portal. Is this expected? It certainly took me a bit to wrap my head around it, but I guess it's fine as long as users don't constantly hop between different sessions... -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
Package: spectrwm
Version: 3.4.1-3
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
As well as being available as a window manager to integrate into some
larger environment, spectrwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/spectrwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/spectrwm-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
But as far as I can tell, spectrwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.
XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow spectrwm to participate in those
specifications.
To reproduce
* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg spectrwm
* reboot
* Log in as the user account, selecting "spectrwm" from the menu of
possible X11 sessions
* Open an xterm and run:
systemctl --user show-environment
(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)
Expected result
===
XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. spectrwm seems to be its
own thing rather than being based on another desktop environment, so
XDG_CURRENT_DESKTOP=spectrwm
would seem appropriate.
This would allow the spectrwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/spectrwm-portals.conf.
Actual result
=
XDG_CURRENT_DESKTOP is unset.
This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of spectrwm who wants a working xdg-desktop-portal will
have to configure it themselves.
At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.
Suggested fix
=
Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/spectrwm.desktop, most likely just "spectrwm":
DesktopNames=spectrwm;
(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)
And then create a /usr/share/xdg-desktop-portal/spectrwm-portals.conf
with whatever portal backends are desired for a spectrwm session,
for example perhaps this:
[preferred]
default=gtk;
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
