Hi Roman,
Roman Scherer <[email protected]> writes: > Starting both xdg-desktop-portal-gtk and xdg-desktop-portal seems to > have fixed the issue: > > https://github.com/r0man/guix-home/commit/6a0b24f76a19ed57c79b89dcdeade682a82922a1 > > But I wonder if this is the best way to do this. If so, maybe we should > have home services for this or integrate it into > home-startx-command-service-type ? No, this is not how xdg desktop portals are supposed to be used. They are dbus services. They should be started by dbus. Moreover the xdg-desktop-portal is responsible for starting individual implementations, users aren't supposed to start them by themselves during normal operation. To let dbus start xdg-desktop-portal, it suffices to have it installed in a profile as long as it's in XDG_DATA_DIRS, like home is. To let xdg-desktop-portal start the implementations, it suffices to install the main portal and the implementation in the same profile, that way you obtain the search path needed for locating the portals. This environment variable also has to be shared with dbus. Since you have done both, the issue seems to be that you haven't imported your environment to dbus with `dbus-update-activation-environment XDG_DESKTOP_PORTAL_DIR DISPLAY` for X, for Wayland it would be `dbus-update-activation-environment XDG_DESKTOP_PORTAL_DIR DISPLAY XDG_CURRENT_DESKTOP WAYLAND_DISPLAY`, possibly after setting XDG_CURRENT_DESKTOP yourself. This has to be called from within X/compositor to obtain the DISPLAY and WAYLAND_DISPLAY so that the portals can know what display to start apps in. Also, it has to be done on startup, before the portals have a chance to start by being called by a program. Importing only DISPLAY might be enough as dbus should already get XDG_DESKTOP_PORTAL_DIR when it starts. Regards Rutherther
