Results of the freedesktop summit

Tue Apr 16 13:06:19 BST 2013

This past week, developers from the KDE, GNOME, Unity and Razor-qt
projects met at the SUSE offices in Nürnberg to improve on collaboration
between the projects by discussing specifications.

See https://en.opensuse.org/openSUSE:2013_Desktop_Summit for more details
and the attendee list.

Here are two versions of the summary of what was discussed: a non-technical
one for press release, and a more technical one from me, with a KDE 
perspective (warning: long email).

==== Press release ===

March 16 2013 - Nürnberg

This past week, developers from the KDE, GNOME, Unity and Razor-qt
projects met at the SUSE offices in Nürnberg to improve on collaboration
between the projects by discussing specifications.

A wide range of topics were covered.

We reached agreement on a specification for a D-Bus interface to be
implemented by applications.  Pending implementation, applications are
now capable of being launched using D-Bus activation instead of by way
of executing a binary.  Changes were also agreed for the desktop entry
specification for applications to advertise this capability.

We reached agreement on a modification to the trash specification to
allow for an efficient means of determining the size of all items in the
trash (for purposes of warning the user when the size is getting too
large).

We defined a new file format to cache and index the contents of all
.desktop files within a particular directory.  This new format will
allow efficient full-text search over desktop files as well as efficient
lookups of various other kinds (eg: which apps support a given file
type) while increasing performance by reducing disk seeks.  It will also
reduce memory consumption because it can be shared by all processes
using mmap.

The in-development kernel D-Bus implementation was presented at the
meeting and representatives from the desktop environments made
suggestions to improve the kernel API to facilitate implementation of
libraries.

We discussed the future of accountsservice and how, going forward, the
project will be sensitive to the needs of desktops other than GNOME.  We
specifically discussed implementation of storing user locale in the
service as well as providing an extension mechanism for structured
storage of arbitrary key/value data, without needing to patch the
service.

We also had initial discussions (with no concrete results) on a wide
range of other topics including D-Bus session management APIs, a
replacement for X11-based startup notification, application intents and
"portals", exporting action groups on D-Bus and adding actions to
context menus in the file browser.

Perhaps most importantly we have come to agreement on a scheme for
improving the maintenance of freedesktop specifications going forward.
One representative from each of GNOME, KDE and Unity will form a joint
maintainer team.  This team will act to monitor and participate in
conversations on the xdg list and decide when consensus has been
reached, which will hopefully revive the usefulness of the xdg list as the
primary point of communication between desktops.

Ryan Lortie (Gnome)
David Faure (KDE)

==== What it means for KDE ====

Table of contents:

1) Standardized and implemented fdo.Application spec for "unique" 
applications.
2) Update desktop spec for the above.
3) Defined standard for size information in trash spec
4) Defined standard for .desktop file cache
5) Sync up between kernel and desktop people about dbus
6) Discussed intents spec
7) AccountService will accept arbitrary key/values, locale stuff is done
8) Very initial discussion on DBus-based session management
9) Initial discussion on DBus actions (exposing GUI actions to DBus)
10) Discussion on contextual-menu file actions in desktop files

Details:

1) Standardized and implemented fdo.Application spec for "unique" 
applications.

This is a standard DBus interface which replaces the KUniqueApplication 
"newInstance" method (and adds a few additional features). I already 
implemented it in the KDE-Frameworks-5 replacement for KUniqueApplication, 
called KDBusService. The whole point of standardizing it is that it becomes 
possible to start (unique) applications by just making a dbus call (which will 
either use DBus activation to launch the application, or will ask the running 
app to "activate", e.g. create a new window or a new tab).

This is really nice because it removes the need for a daemon like klauncher 
for that particular purpose (launching an app and waiting for it to register 
to DBus before talking DBus to it). The dbus server itself does the job for 
us. This doesn't work for non-unique apps though (e.g. konqueror and its 
multiple processes), but the suggestion for that use case was to write a 
unique-app frontend (= dbus service) which delegates the task to a separate 
(non-unique) process. This requires support from the apps though, unlike the 
current `kstart --service foo.desktop` that any script can use to start an 
app, wait for it to register to dbus, and then talk dbus to it. But maybe I'm 
the only one using that :)

Implementation status:
* KDBusService now supports this dbus interface (see 608bccad0744 in kdelibs-
frameworks), but support for startup notification is missing.
* This led me to first re-implement startup notification support in Qt 5 (it 
got lost with the rewrite to QPA) :
https://codereview.qt-project.org/53865

Related: setting a property _DBUS_UNIQUE_NAME on every window, to find out
how to talk to dbus to it (service name). See discussion on xdg list starting 
15-Dec-2011. With this standardized interface, it makes even more sense
(and would be available for non-unique-apps too). I'm trying to implement this 
in kdelibs4 kmainwindow.

2) Update desktop spec for the above.

For this to work from launchers, two things are needed:
* the desktop file should be named after the dbus service, e.g. 
org.kde.kontact.desktop so that we know it will register as org.kde.kontact
(this replaces our X-DBUS-ServiceName non-standard hack)
* the desktop file should contain the new key DBusActivatable=true.

This makes it possible for app launchers to make the DBus call on 
org.kde.kontact in order to start it (whether it's already running or not).

3) Defined standard for caching directory sizes in trash spec

This is to speed up the determination of the size of the trash, in order to 
warn the user if it's full. It will help with 
https://bugs.kde.org/show_bug.cgi?id=245482 (but that bug also contains a 
usability problem).

Status: posted a proposal to the XDG list during the meeting, for further 
discussion and finalization, and we have reached an agreement on all details 
now.

4) Defined standard for .desktop file cache

This is something that I've been wanting for quite some time already: 
replacing the ksycoca cache with something that is updated when .desktop files 
are installed, without the need for directory watching or slow kbuildsycoca on 
login. Much like update-mime-database works. The existing tool update-desktop-
database will be updated to also create this binary on-disk cache, and should 
be run by package post-installs (but we'll also detect the case where the 
cache wasn't updated, by looking at directories mtime, and we'll update it on-
demand; so, unlike update-mime-database, this won't be strictly required, just 
a performance improvement).

We designed the format of the binary cache so that it's easy to use without
memory allocations (just mmap), exactly like the shared-mime-info cache.

Status: Ryan is working on adding the cache generation to update-desktop-
database, and on an implementation of the use of the cache. I'll look into 
either using the latter (he's using BSD license to make that impossible), or 
implementing that with Qt classes myself (as I did for the mime spec).

On our side I'm still unsure about where to put the API for it; it could be 
the new implementation of KService + KMimeTypeTrader, or it could be in Qt, 
but desktop files are unix-only, mostly. glib actually implements application 
lookup on Windows using win32 API (which looks into the registry) rather than 
desktop files, ideally Qt should do the same, but who wants to implement 
that... (well, actually I remember someone looking into adding that to kded a 
few years ago...).

Since the cache is per-directory, there'll be a global and local one for 
application desktop files, but what's nice is that if we keep any sort of 
Type=Service desktop files in other dirs, like we do in kde4, we can also 
generate a cache for those using the same tool.

5) Sync up between kernel and desktop people about dbus

When I arrived, Lennart was showing details of his current implementation of 
DBus into the Linux Kernel.
This was mostly too low-level for me (and arriving in the middle of it didn't 
help), but what I learned was the big plan around this, the idea of contained 
applications for security, with the kernel as intermediary (with security 
policies) between the secure app and the rest of the world (see also next 
item).
Thiago, if you're not yet following this topic, I have a strong feeling that 
you should :-)

6) Discussed intents spec

Jérome Leclanche from Razor-qt posted some time ago a proposal for a generic 
way of finding the preferred file manager, email client, and so on. Basically 
a standard for what we call X-KDE-ServiceType, although this is mostly about 
finding apps (not plugins).
He called this "intents", but chose that name before Android, so nowadays
it could be a bit confusing, so maybe we'll call this differently.
This feature could also be used to distinguish between image viewer
and image editor, for instance, something which is missing in the current
basic mime->apps associations. "Edit" would be an intent, and apps can 
implement that intent for specific mimetypes.

During the meeting we extended this idea to also support dbus calls, not just
running executables. For instance, an application wants to take a picture with
the camera, it can use a standard intent string for that, look up the 
preferred associated .desktop file(s), make the call to it (another reason for 
naming the desktop file after the dbus service name), and get the picture in 
return.
The desktop file would mention the name of the dbus interface implemented
by the application, which in turn defines the method(s) to use.
This also fits with the contained apps idea, since it's a well-defined way
for a contained app to get a service (e.g. make a phone call, take a picture, 
etc.) from the "system" (desktop). When talking about intents implemented by a
DBus interface, we called this "portal" (but actually this part is starting to 
look even more like Android intents, from what I heard).

Status: Jérome will post an updated proposal to the xdg list

7) AccountsService will accept arbitrary key/values, locale stuff is done

AccountsService stores extra data for system users (e.g. face icon, )
KDE uses AccountsService in LightDM-KDE and Alex Fiestas' user-manager KCM.
The discussion was about vendor extensions such as LDAP, Exchange...
(for remote logins, which is a part of AccountService we don't use currently,
but this could be interesting one day).

Status: Stef Walter will add that to AccountsService.
About AccountsService usage on the KDE side, talk to Alex Fiestas.

8) Very initial discussion on DBus-based session management

X11/XSM will not always be around, so it kind of makes sense to move session
management to DBus, then it would also work on Wayland / Mir.
Gnome doesn't plan to implement saving of applications on logout to restore
them on login, but we talked about a way to add that on top of the basic spec.

Status: Nothing finalized in this area, needs further input. If someone's 
interested I have a few notes about the basic idea.

9) Initial discussion on DBus actions (exposing GUI actions to DBus)

This would be an extension of point 1, to add a standard dbus interface
for triggering actions from the application. QActions, for us.
Could be useful for generic introspection and scripting, but also possibly
for calling that from .desktop files.

Status: gtk has a dbus interface for this, kdeui has one too, we should 
compare them and standardize.

10) Discussion on contextual-menu file actions in desktop files

The context menu on files (in e.g. dolphin) has an "Actions" submenu,
but currently this is populated with kde-specific desktop files installed
into services/ServiceMenus. Application developers would like these actions
to appear in all desktops.
The plan would be to add this to application desktop files, with a new
key and new groups, like

FileActions=compressHere;compressAsZip;...

[File Action compressHere]
Name=Compress here
Icon=ark
Exec=ark --changetofirstpath --add --autofilename tar.gz %F

[File Action compressAsZip]
Exec=...

Very much like our current 
/usr/share/kde4/services/ServiceMenus/ark_addtoservicemenu.desktop, in fact.
However this isn't standardized yet, we need to get input from other 
filemanager authors, like Alex Larsson (who couldn't attend).

Thanks for reading this far. Input welcome. If you're replying to one specific 
topic only, please adjust the Subject line accordingly.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5