Update FAQ section about save file dialogs
This PR updates the suggested method to fix the Save FIle dialog according to this comment: https://github.com/DISTRHO/Cardinal/issues/135#issuecomment-1659151269. The current suggestion doesn't fix the problem and results in the following error.
$ systemctl enable xdg-desktop-portal --user --now
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
The suggestion introduced in this PR seems to be a proper workaround for the issue.
I've also removed the note about the "Open" dialog because it turned out to be wrong for me: the "Open" dialog didn't appear until I applied the fix.
I recall the command about systemd service being needed too, as it is not guaranteed that it will run by default.
That being the systemctl enable xdg-desktop-portal --user --now.
but I dont run these kinda minimal setups myself, so we need a consensus from the people that do.
in my opinion we should have more information instead of less, just in case 1 thing works for a user and the other does not. why did you remove the systemctl command?
@falkTX not all distros run systemd though. I had this issue on Devuan, which ships without systemd (and I had to manually run xdg-desktop-portal every time)
@falkTX not all distros run systemd though. I had this issue on Devuan, which ships without systemd (and I had to manually run xdg-desktop-portal every time)
sure but the new replacement command is also systemd related. so the situation for this matter doesnt change.
why did you remove the systemctl command?
Because I believed that it doesn't change anything. But I ran the test now and, apparently, I was wrong. Turns out, I need more time to cook this PR, maybe a couple of days.
not all distros run systemd though
Fair enough, I'll look into this and add a section for systemd-less systems.