Open hosiet opened 11 months ago
ammen99
commented
11 months ago Hi, this is an interesting question because Wayfire itself is not a full desktop environment. We don't set XDG_DESKTOP_ENVIRONMENT either. Maybe we can have a .conf file in the repo but not install it by default, similarly to what we do about the session and example ini file?
About preferred portals, the wlr portal is definitely used for screenshots but aside from that, idk.
marcusbritanicus
commented
11 months ago Since wayfire + wf-shell provides a minimal DE experience, it would be beneficial to use the -gtk portal along with -wlr, mainly because wf-shell is written in gtk.
@ammen99 Do you think it would make more sense to ship this portal file with wf-shell, without which all that you'll have is a gray screen and a mouse? After all isn't it wf-shell that provides a DE-like experience?
ammen99
commented
11 months ago If anything, wf-install should be the place, it installs the session file and creates the script which sets the env var. I was thinking of the main repo simply because it will likely be easier for packagers this way.
smcv
commented
10 months ago In more tightly-integrated desktop environments like GNOME, I think it generally makes sense to put the ${desktop}-portals.conf in the same package as the /usr/share/xsessions or /usr/share/wayland-sessions entry, but that isn't strictly required: it's fine for it to be in any package that would be pulled in as a dependency by that one. For example, GNOME ships its equivalent of this file in gnome-session, but it would be equally valid to have it in gnome-shell or even libgnome-desktop. The only thing that's important is that it's somewhere, and preferably in a package that is reasonably obvious for desktop environment developers, packages and advanced users to modify if the set of preferred portals changes.
The package that ships ${desktop}-portals.conf does not necessarily even need a dependency on the portal implementations themselves - although in packaging systems that have the concept of a weak dependency (like Debian's Recommends and Suggests), it would make sense to add one of those.
Either wf-shell or wayfire seems like a plausible place to put this, but I would personally lean towards wayfire because it's wayfire that provides https://github.com/WayfireWM/wayfire/blob/master/wayfire.desktop.
I would recommend putting it in some project that distro packagers are expected to package, like wf-shell or wayfire, rather than in a project that is only used when installing manually, like wf-install.
wf-install should be the place, it installs the session file and creates the script which sets the env var
Doesn't wayfire install https://github.com/WayfireWM/wayfire/blob/master/wayfire.desktop?
Some login managers like gdm and lightdm set XDG_CURRENT_DESKTOP based on the value of DesktopNames, so it will get a value even if you don't provide a launcher script that explicitly sets it.
flexibeast
commented
9 months ago Adding my two bits:
From what i can tell, having been reading about all this stuff just now (and creating a page on the Gentoo wiki as a result), xdg-desktop-portal isn't about whether one is using a Desktop Environment™ per se; it's about providing functionality that is typically expected in Desktop Environments, but which might be used with other 'desktops' (i.e. GUI environments such as WMs) as well.
i haven't used wf-install to install Wayfire, and wf-shell isn't enabled either, but i nevertheless want to make use of xdg-desktop-portal functionality like ScreenCast, via the wlr portal (which i actually wanted to do for #2063). Similarly, even though i'm not actually running a DE, i still want XDG_CURRENT_DESKTOP set in a way that indicates my current GUI environment to programs that might use that variable.
My suggestion is to include a file wayfire-portals.conf[a] in the 'wayfire' project, and that by default this file is installed to /usr/share/xdg-desktop-portal/; this provides defaults without package maintainers having to do anything special, and also provides a file that users can copy to $XDG_CONFIG_HOME/xdg-desktop-portal/ and tweak as desired.
[a] The portals.conf(5) man page says that case-folding to lower-case should be performed on the desktop name.
smcv
commented
9 months ago xdg-desktop-portal isn't about whether one is using a Desktop Environment™ per se; it's about providing functionality that is typically expected in Desktop Environments, but which might be used with other 'desktops' (i.e. GUI environments such as WMs) as well
x-d-p is about providing functionality using an implementation that is appropriate for your particular GUI environment, whatever that might be, by dispatching requests to a GUI-environment-specific backend.
If you're using a well-known, relatively tightly-integrated desktop environment like GNOME or KDE Plasma, then the right thing to do (at least as a default) is to use that desktop environment's backend implementation(s) - GNOME has several smaller backends, KDE has one large backend, and both of those models are equally valid. Part of the desktop environment maintainers' job is to set that up so that the right thing will happen automatically.
If you're using a loosely-coupled, assemble-it-yourself GUI environment consisting of multiple smaller pieces, then the system integration might be done by the desktop shell maintainers, or by packagers in a Linux distribution, or even by end users, depending on how difficult the various maintainers want to make it. I would personally say that there is a lot of value in having a default installation try to do something reasonable and useful, even if it isn't necessarily what every user will want; users who know what they want can still override that default and get their desired different behaviour.
even though i'm not actually running a DE
I would argue that you are running a DE, it just isn't necessarily one that has a name, and its precise contents might be unique to your specific system. There isn't really any functional difference between an integrated desktop environment like GNOME or KDE Plasma, and a user-specific combination of a window manager/compositor, a desktop shell, an o.fd.Notifications implementation, a polkit agent, an xdg-desktop-portal backend and so on (except that in the second case, you're more likely to have a piece missing that will break some app's expectations).
flexibeast
commented
9 months ago @smcv:
I would argue that you are running a DE, it just isn't necessarily one that has a name, and its precise contents might be unique to your specific system.
Sure, fair enough; i'm fine with saying that i use a hand-made artisinal DE. 😉 But my overall point was basically that the word 'desktop' in all this portal stuff shouldn't be taken to imply that portals are only applicable in contexts involving a named, 'official', DE.
I would personally say that there is a lot of value in having a default installation try to do something reasonable and useful, even if it isn't necessarily what every user will want; users who know what they want can still override that default and get their desired different behaviour.
Very much agreed.
ammen99
commented
9 months ago Alright, I guess we can add a simple default - users can override it if they want. PRs welcome.
Forwarding downstream bug report at https://bugs.debian.org/1050914 :
On Thu, 31 Aug 2023 12:33:28 +0100 Simon McVittie [smcv@debian.org](mailto:smcv@debian.org) wrote:
As the Debian wayfire package maintainer, I am interested in (1) which xdg-desktop-portal implementation do you consider to be preferred, and (2) do you wish to ship this file in upstream wayfire project or let downstream Linux distributions handle it individually.