DBus-activated applications

[David Faure]

kdelibs4 had KUniqueApplication, where running the app a second time would
make a DBus call to the running instance and then quit.

The new idea, as a result of last year's freedesktop summit, is to improve
upon this and generalize it : even the first instance can be started with a
DBus call, using DBus activation (these .service files installed in
share/dbus-1/services).
Which means that whoever wants to start such an application doesn't need to
start a process anymore, but can just make a dbus call, whether the app is
already running or not.

This makes things faster for the second invocation (no process needed), and
allows more features: for instance we can solve the issue of leaking temporary
files (e.g. for kmail attachments) by passing a file descriptor (to a temp
file, unlinked by the caller) to an application via DBus, while we can't do
that on the command line. It also allows more actions than just "open a new
window", e.g. specific desktop files can let plasma offer "open new tab" etc.

The way to do this is fully specified in the desktop entry spec: both the DBus
interface for doing this (called org.freedesktop.Application), and the new key
for .desktop files to say "I can be activated via DBus".

This dbus interface is implemented by KDBusService in KF5's kdbusaddons,
which is the replacement for KUniqueApplication.
The starting of dbus-activatable apps is not implemented yet, but that's easy
and I'll do it shortly (in KToolInvocation, I guess, and ensuring KRun ends up
there).

What I need from you:

* if you can, make your apps "unique" by porting them to KDBusService in KF5
(and maybe to KUniqueApplication in kde4 if you want to do things more
incrementally).

* name the application .desktop file using reverse-dns-notation, e.g.
org.kde.kmail.desktop.
This way we can match the desktop file to the dbus service provided by the
application, in both directions.

I (and the spec) suggest that we use org.kde.kfoo.desktop for all apps, for
consistency, not just for dbus-activatable unique apps.
Please help renaming all the .desktop file :)

[Thiago Macieira]

Post by David Faure
The new idea, as a result of last year's freedesktop summit, is to improve
upon this and generalize it : even the first instance can be started with a
DBus call, using DBus activation (these .service files installed in
share/dbus-1/services).

Did you have a chance to discuss with Lennart and Kay about systemd+kdbus not
using /usr/share/dbus-1/services, but systemd unit files instead?

[David Faure]

Post by Thiago Macieira

Post by David Faure
The new idea, as a result of last year's freedesktop summit, is to improve
upon this and generalize it : even the first instance can be started with
a DBus call, using DBus activation (these .service files installed in
share/dbus-1/services).

Did you have a chance to discuss with Lennart and Kay about systemd+kdbus
not using /usr/share/dbus-1/services, but systemd unit files instead?

Not in details. I heard this was planned at some point, but it didn't seem to
be for right now. In any case we'll still need to install .service files for
non-systemd/kdbus systems...

On the other hand we had an interesting discussion on setting environment
variables (XDG_CURRENT_DESKTOP, XDG_DATA_DIRS etc.) in a way that affects
dbus-activated applications. Right now it's as simple as setting them before
starting the dbus daemon, but the idea of replacing the session bus with a
user bus would break that (e.g. when logging into a TTY before logging into an
X session, the env vars wouldn't be set). Lennart was mentionning an API for
setting env vars into the running user bus, but both Ryan and me were rather
in favour of getting a session bus back :). To be continued...