Allow DynamicLauncher portal creating files on the Desktop

[JakobDev]

Right now, the DynamicLauncher portal can only create launchers in the menu (~/.local/share/applications). But it is not possible to create launchers on the Desktop (XDG_DESKTOP_DIR). There are a lot of people who want launchers on the Desktop and there are a lot of programs who offers creating launchers on the Desktop e.g. Heroic Games Launcher.

I suggest adding 3 new options to PrepareInstall:
app_menu: Creating a Launcher in the Menu (~/.local/share/applications). Defaults to true.
desktop: Creating a Launcher on the Desktop (XDG_DESKTOP_DIR). Defaults to false.
app_user_choice: When set the true, the PrepareInstall has 2 checkboxes: Menu and Desktop. The user can choose itself if he want the Launchers on Menu and/or Desktop. If this is used, the 2 former options decide if the Checkboxes are checked, when the Dialog appears. Defaults to false.
The names of the options might not be ideal and might be chanced.

@mwleeds Is this easy to add to the current codebase or need this a lot f more work?

[mwleeds]

Some desktop environments, e.g. GNOME, don't allow (anymore) icons on the desktop. So this would need to be a feature that could be optionally provided by each backend, and the information of whether it's available would need to be exposed in the portal interface (probably in a property analagous to SupportedLauncherTypes).

So, this feature is a medium complexity project, and not one I have time for any time soon.

[JakobDev]

You are thinking way to complex. All the Portal need to do is to place the .desktop file in the XDG_DESKTOP_DIR and clean it up when needed. If the DE have no Desktop Icons, it will simply not using the .desktop files in this Directories. As far as I know (I#m using KDE) there is Plugin for files on the Desktop, what would make this even more complex.

Your solution also sounds like it will be even more complex for Programers to implement this at it already is.

If creating Launchers on the Desktop is not allowed, the Portal is unusable for a lot of Programs.

[mwleeds]

The problem with what you're proposing is that's an awful user experience on DEs such as GNOME. If an app offers to install an icon to the desktop, and I as a naive user click through to try to do so, and then no icon appears on the desktop, that is a bug from the user's perspective. And from GNOME's perspective the lack of icons on the desktop is not a bug; it's just intentionally not a supported feature. So the portal interface has to be able to inform apps when the feature is unsupported; otherwise the UX is awful.

[JakobDev]

Maybe the DE could show a Message that in case the App tries to install files on the Desktop. You could additionally add a method to ask if the DE supports Desktop icons. Or the User is always ask, if he want a Launcher in the Menu, on Desktop or both. The App can only decide, which Option is preselected. In case the DE don't support Desktop icons, the Dialog doesn't contains Options and it is just installed in the Menu.

Don't get me wrong, I understand your indention, but the more you overengineere this, the less people will use probably. Especially if the App from a single Developer who uses a DE with Desktop icons. You should made this as easy as possible to use for Developers and make the DE handle the most work.

[mwleeds]

If I understand your comment correctly we're on the same page now. The portal needs to inform apps of whether installing to the desktop is supported so the app can adjust its interface accordingly. That is not over-engineering.

[JakobDev]

I think the easiest solution currently is do not touch the D-Bus interface. The Backend implementation has the possibility to add 2 Checkboxes to the PrepareInstall Dialog: Menu and Desktop. The user can choose if he want a Launcher in the menu, the Desktop or both. If a DE does not supported Desktop launchers, it will just not display the Checkboxes.

So, as far as I'm understand this, the only thing you need to do is to implement a possibility for Backends if the Launcher was created on Menu, Desktop or both. Gnome will always tell that the Launcher was created in the Menu. Other Desktops like KDE will tell what the User has selected.

That would be enough to make the DynamicLauncher Portal useable for everyone now.

If you have more time at some point in the future, you can implement a Method to ask if a DE supports Desktop icons.

What do you think?

[mwleeds]

I think the easiest solution currently is do not touch the D-Bus interface. The Backend implementation has the possibility to add 2 Checkboxes to the PrepareInstall Dialog: Menu and Desktop. The user can choose if he want a Launcher in the menu, the Desktop or both. If a DE does not supported Desktop launchers, it will just not display the Checkboxes.

So, as far as I'm understand this, the only thing you need to do is to implement a possibility for Backends if the Launcher was created on Menu, Desktop or both. Gnome will always tell that the Launcher was created in the Menu. Other Desktops like KDE will tell what the User has selected.

That would be enough to make the DynamicLauncher Portal useable for everyone now.

If you have more time at some point in the future, you can implement a Method to ask if a DE supports Desktop icons.

What do you think?

It would be possible to leave the app-facing interface (org.freedesktop.portal.DynamicLauncher) unchanged and only change the back-end interface (org.freedesktop.impl.portal.DynamicLauncher) to return the information about whether to install to the menu, the desktop, or both in the results vardict of the PrepareInstall() method. That is needed because it's the front-end that does the actual installation of the launcher, not the back-end.

Whether that's actually a good idea depends on whether applications would need to know where the launcher is being installed to make any decisions about whether to use the portal or what UI to use for triggering the portal flow. It's conceivable that adding the information of whether installing to the desktop is supported to the app-facing interface could be done in a later release, but probably it would make sense to just do it all at once.

[JakobDev]

I don't think most programs do not care about what happens to the .desktop files. They are just created when the User clicks a Button. If a Program fully uses the Portal it does not need to Display anywhere in the UI if the Launcher is installed on the Menu or the Desktop.

[orowith2os]

Why couldn't this responsibility be pushed off to the portal implementation to decide? An app probably wouldn't really care where the desktop file is installed, only the user. That's not really something an app needs to be aware of. It could be added to the portal backend API as an option to install or symlink the desktop file to the appropriate desktop directory, and exposed to the user on desktops that support it. If a desktop doesn't support creating files on a desktop, worst case, it goes unused on that desktop, and life goes on.

But, now, a question: what if someone modifies their desktop to support desktop files? GNOME has extensions like that. Would its portal implementation be able to adapt to that too? Should it? Probably a conversation more fit for GNOME channels, but something to think about nonetheless.