D-Bus activation

[jpnurmi]

• declare the firmware-updater app activatable in the .desktop file
• call one of the d-bus activation methods [*] from firmware-notifier

Not 100% sure which one is correct but org.gtk.Application.CommandLine sounds promising that it might go straight to our command-line handler. :)

[d-loose]

In principle this works quite well (see https://github.com/d-loose/firmware-updater/tree/dbus).

Issues:

• the GTK application created by flutter doesn't seem to use the standard GApplication command line parsing as described here. This means any DBus method invocation (e.g. simply navigating to com.canonical.firmware_updater in d-feet) will launch the application. I don't think it's a problem with gtk_application.dart, as I get the same behavior with flutter's simple 'hello world' application and a service file that looks like this:

  [D-BUS Service]
  Name=com.example.hello-world
  Exec=/path/to/hello-world --gapplication-service

• I had to use daemon: simple in snapcraft.yaml in order to be able to use activates-on [dbus]. Activating firmware-updater via DBus from firmware-notifier (or anywhere else) works just fine. However the snap doesn't provide the firmware-updater command any longer. As far as I understand there's no mechanism to provide DBus-activation for simple applications rather than user services in snapcraft yet.

@oSoMoN do you have any ideas concerning the GTK part?

[jpnurmi]

Would it help to either a) call the base class implementation of local_command_line to let it handle --gapplication-service, or b) change the app to use the command-line signal instead of overriding local_command_line?

[d-loose]

133 resolves the GTK issue for now :)

Thanks @jpnurmi!

[jpnurmi]

yay :) what do we have left? only the snapcraft / dbus service part?

[d-loose]

Yes, it would be great to make bin/firmware-updater DBus-activatable without turning it into a user daemon. As far as I can tell snapcraft also doesn't provide a way to generate a DBus service file that passes the --gapplication-service parameter to the binary yet.

[jhenstridge]

D-Bus session bus activation is not currently possible with current snapd: it depends on user session daemons, which are currently gated behind a feature flag that's disabled by default.

With it enabled, you'd need to do something like this:

slots:
  dbus-slot:
    interface: dbus
    bus: session
    name: com.canonical.firmware_updater
apps:
  foo:
    command: ...
    daemon: simple # or alternatively dbus, if you want the service to be marked ready when it registers the name
    daemon-scope: user
    activates-on: [dbus-slot]

That would result in the snap providing a D-Bus activatable user daemon. If you want it to be launchable as an application too, you'd need a second entry point into the snap with an associated desktop file. If you're using GApplication-style single instance behaviour, you could have the command execute something like gapplication launch com.canonical.firmware_updater "$@" (probably via a shell script, if you're relying on the gapplication binary from the gnome platform snap).

We can't yet use DBusActivatable=true in the desktop file for snap apps, since the desktop files written out by snapd won't match the D-Bus name of the app. Fixing that is on the todo list, but no clear ETA.

[d-loose]

Thanks - that helps to make it work for now :) Unfortunately this re-introduces the issue that the application is launched on all sorts of DBus calls, like simply navigating to its entry in d-feet, since the service file generated by snapcraft doesn't pass --gapplication-service:

[D-BUS Service]
Name=com.canonical.firmware_updater
Comment=Bus name for snap application firmware-updater.firmware-updater-app
SystemdService=snap.firmware-updater.firmware-updater-app.service
Exec=/usr/bin/snap run firmware-updater.firmware-updater-app
AssumedAppArmorLabel=snap.firmware-updater.firmware-updater-app
X-Snap=firmware-updater

I'd be happy to ignore this limitation for now, though.