From kde-core-devel Tue Apr 16 12:06:19 2013 From: David Faure Date: Tue, 16 Apr 2013 12:06:19 +0000 To: kde-core-devel Subject: Results of the freedesktop summit Message-Id: <1394549.VkPtykuPsj () asterix> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=136611595505790 This past week, developers from the KDE, GNOME, Unity and Razor-qt projects met at the SUSE offices in N=C3=BCrnberg to improve on collabo= ration between the projects by discussing specifications. See https://en.opensuse.org/openSUSE:2013_Desktop_Summit for more detai= ls and the attendee list. Here are two versions of the summary of what was discussed: a non-techn= ical one for press release, and a more technical one from me, with a KDE=20 perspective (warning: long email). =3D=3D=3D=3D Press release =3D=3D=3D March 16 2013 - N=C3=BCrnberg This past week, developers from the KDE, GNOME, Unity and Razor-qt projects met at the SUSE offices in N=C3=BCrnberg to improve on collabo= ration 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 th= e 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 efficien= t lookups of various other kinds (eg: which apps support a given file type) while increasing performance by reducing disk seeks. It will als= o 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. W= e 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) =3D=3D=3D=3D What it means for KDE =3D=3D=3D=3D Table of contents: 1) Standardized and implemented fdo.Application spec for "unique"=20 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 don= e 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"=20 applications. This is a standard DBus interface which replaces the KUniqueApplication= =20 "newInstance" method (and adds a few additional features). I already=20= implemented it in the KDE-Frameworks-5 replacement for KUniqueApplicati= on,=20 called KDBusService. The whole point of standardizing it is that it bec= omes=20 possible to start (unique) applications by just making a dbus call (whi= ch will=20 either use DBus activation to launch the application, or will ask the r= unning=20 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 klaun= cher=20 for that particular purpose (launching an app and waiting for it to reg= ister=20 to DBus before talking DBus to it). The dbus server itself does the job= for=20 us. This doesn't work for non-unique apps though (e.g. konqueror and it= s=20 multiple processes), but the suggestion for that use case was to write = a=20 unique-app frontend (=3D dbus service) which delegates the task to a se= parate=20 (non-unique) process. This requires support from the apps though, unlik= e the=20 current `kstart --service foo.desktop` that any script can use to start= an=20 app, wait for it to register to dbus, and then talk dbus to it. But may= be I'm=20 the only one using that :) Implementation status: * KDBusService now supports this dbus interface (see 608bccad0744 in kd= elibs- frameworks), but support for startup notification is missing. * This led me to first re-implement startup notification support in Qt = 5 (it=20 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 st= arting=20 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 impleme= nt this=20 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.=20 org.kde.kontact.desktop so that we know it will register as org.kde.kon= tact (this replaces our X-DBUS-ServiceName non-standard hack) * the desktop file should contain the new key DBusActivatable=3Dtrue. This makes it possible for app launchers to make the DBus call on=20 org.kde.kontact in order to start it (whether it's already running or n= ot). 3) Defined standard for caching directory sizes in trash spec This is to speed up the determination of the size of the trash, in orde= r to=20 warn the user if it's full. It will help with=20 https://bugs.kde.org/show_bug.cgi?id=3D245482 (but that bug also contai= ns a=20 usability problem). Status: posted a proposal to the XDG list during the meeting, for furth= er=20 discussion and finalization, and we have reached an agreement on all de= tails=20 now. 4) Defined standard for .desktop file cache This is something that I've been wanting for quite some time already:=20= replacing the ksycoca cache with something that is updated when .deskto= p files=20 are installed, without the need for directory watching or slow kbuildsy= coca on=20 login. Much like update-mime-database works. The existing tool update-d= esktop- database will be updated to also create this binary on-disk cache, and = should=20 be run by package post-installs (but we'll also detect the case where t= he=20 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 require= d, just=20 a performance improvement). We designed the format of the binary cache so that it's easy to use wit= hout memory allocations (just mmap), exactly like the shared-mime-info cache= . Status: Ryan is working on adding the cache generation to update-deskto= p- database, and on an implementation of the use of the cache. I'll look i= nto=20 either using the latter (he's using BSD license to make that impossible= ), or=20 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 coul= d be=20 the new implementation of KService + KMimeTypeTrader, or it could be in= Qt,=20 but desktop files are unix-only, mostly. glib actually implements appli= cation=20 lookup on Windows using win32 API (which looks into the registry) rathe= r than=20 desktop files, ideally Qt should do the same, but who wants to implemen= t=20 that... (well, actually I remember someone looking into adding that to = kded a=20 few years ago...). Since the cache is per-directory, there'll be a global and local one fo= r=20 application desktop files, but what's nice is that if we keep any sort = of=20 Type=3DService desktop files in other dirs, like we do in kde4, we can = also=20 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 implementati= on of=20 DBus into the Linux Kernel. This was mostly too low-level for me (and arriving in the middle of it = didn't=20 help), but what I learned was the big plan around this, the idea of con= tained=20 applications for security, with the kernel as intermediary (with securi= ty=20 policies) between the secure app and the rest of the world (see also ne= xt=20 item). Thiago, if you're not yet following this topic, I have a strong feeling= that=20 you should :-) 6) Discussed intents spec J=C3=A9rome Leclanche from Razor-qt posted some time ago a proposal for= a generic=20 way of finding the preferred file manager, email client, and so on. Bas= ically=20 a standard for what we call X-KDE-ServiceType, although this is mostly = about=20 finding apps (not plugins). He called this "intents", but chose that name before Android, so nowada= ys 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 curre= nt basic mime->apps associations. "Edit" would be an intent, and apps can=20= implement that intent for specific mimetypes. During the meeting we extended this idea to also support dbus calls, no= t just running executables. For instance, an application wants to take a pictu= re with the camera, it can use a standard intent string for that, look up the=20= preferred associated .desktop file(s), make the call to it (another rea= son for=20 naming the desktop file after the dbus service name), and get the pictu= re in=20 return. The desktop file would mention the name of the dbus interface implement= ed 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 pi= cture,=20 etc.) from the "system" (desktop). When talking about intents implement= ed by a DBus interface, we called this "portal" (but actually this part is star= ting to=20 look even more like Android intents, from what I heard). Status: J=C3=A9rome will post an updated proposal to the xdg list 7) AccountsService will accept arbitrary key/values, locale stuff is do= ne 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 curr= ently, 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 se= ssion management to DBus, then it would also work on Wayland / Mir. Gnome doesn't plan to implement saving of applications on logout to res= tore them on login, but we talked about a way to add that on top of the basi= c spec. Status: Nothing finalized in this area, needs further input. If someone= 's=20 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 possi= bly for calling that from .desktop files. Status: gtk has a dbus interface for this, kdeui has one too, we should= =20 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 install= ed into services/ServiceMenus. Application developers would like these act= ions 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=3DcompressHere;compressAsZip;... [File Action compressHere] Name=3DCompress here Icon=3Dark Exec=3Dark --changetofirstpath --add --autofilename tar.gz %F [File Action compressAsZip] Exec=3D... Very much like our current=20 /usr/share/kde4/services/ServiceMenus/ark_addtoservicemenu.desktop, in = fact. However this isn't standardized yet, we need to get input from other=20= filemanager authors, like Alex Larsson (who couldn't attend). Thanks for reading this far. Input welcome. If you're replying to one s= pecific=20 topic only, please adjust the Subject line accordingly. --=20 David Faure, faure@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5