Document actions handling for launchers

[danirabbit]

Problem

At the moment we tell developers that their app has to handle command line arguments for actions and we recommend using the exec line for actions, but it appears this isn't necessary with dbus activation

Proposal

Document:

• [ ] adding DBusActivatable=true to the main section of your desktop entry
• [ ] name app actions the same as they're named in your app's source code

This appears to "just work™" without having to add manual action handling

Prior Art (Optional)

No response

[Antolius]

This sounds super interesting! GAction-s are, at least in my experience, nicer to work with than command line arguments. Exposing features through GAction (with proper accels etc.) also leads to more consistent end-user experience. Users will be able to access the same functionality from outside of the app using launch actions and from within using keyboard shortcuts (and perhaps buttons, etc.).

I put together a demo app to verify the proposed solution: Actions Launcher Demo. I had to install a service file for D-Bus launching to work, but that's it as far as the application side goes.

The demo app's launch actions can be triggered from the applications menu, and the app handles them as expected. (The Lock action presents a closed lock icon in the app window, and the Unlock action presents an open lock.) However, I encountered problems with triggering actions from the Dock. It lists actions fine, in fact it includes the icons, which are not present in applications menu. However, I think it does not use the D-Bus launch mechanism and so it does not activate the actions.

I tried to track down the issue, and I think this is the difference:

• Applications menu uses the DesktopAppInfo.launch_action method in context menu and search results.
• Dock, on the other hand, in context menu delegates to its System class' internal_launch method which doesn't appear to take the action into account.

I'm not really familiar with Dock's source code, so I may be reading it wrong. There might also be something wrong with the demo app I made. I would appreciate it if someone could double-check my assumptions. In case my hunch turns out to be correct I can open an issue on Dock's project and try to resolve it there. Once that is sorted out I can open a pull request for updating the developer documentation here.

[danirabbit]

I also had problems with the dock. We're planning to do a rewrite of the dock for Wayland anyways, so depending on how much effort it is to fix in the current dock we may just want to wait to switch over docs until that time

[Antolius]

Tnx for the quick confirmation!

Ok, I see you're already working on adding this for the new dock.🤘

I'll try to adjust the action handling in the current Plank-based implementation. If that proves to be too complicated we can wait for the new dock to fix it.

And I can prepare an update to dev documentation here, in case we are ok with documentation being updated before the dock support (either version) lands.

[danirabbit]

@Antolius that all sounds great, thank you for taking on this issue!

[Marukesu]

I'm +1 on recommending DBusActivation, but i believe this should be part of an full rework over how to use the GLib.Application class, i see a lot of applications that do everything on activate() and with DBusActivation it won't be called when launching an action.

I would keep the exec line, since it's used as an fallback, thorough.

[Antolius]

I'm +1 on recommending DBusActivation, but i believe this should be part of an full rework over how to use the GLib.Application class, i see a lot of applications that do everything on activate() and with DBusActivation it won't be called when launching an action.

I was thinking about updating examples in the Actions page as well. I see this issue as related to #179, so one pull request should probably address both.

I could go a step further and update other examples through the docs to use the startup method instead of activate. However, I don't think all the initialization necessarily needs to be moved. For example, GNOME Developer Documentation says:

When your application starts, the startup signal will be fired. This gives you a chance to perform initialisation tasks that are not directly related to showing a new window.

I took this to mean that creating widgets and presenting the main window is still best handled in the activate method. What do you think?

I would keep the exec line, since it's used as an fallback, thorough.

Yeah, it has to stay in the .desktop file, flatpak build fails without it.

[Marukesu]

I took this to mean that creating widgets and presenting the main window is still best handled in the activate method. What do you think?

Yes, i mean, activate() should only handle the creation and presentation of the window.

Things like, calling init() functions, owning DBus names, registering actions, all of that should be done on startup()