OLPC and .service files in a users home directory

[Havoc Pennington]

Thiago Macieira wrote:
>> I've seen a couple side mentions of merging .service and .desktop; can
>> someone fill me in on the goal of that? Other than the two both being in
>> .ini format, I don't see the similarity...
> 
> The fact that they are so very similar. We have many .desktop editors as 
> well as validation tools.

If you have a .ini editor it will work on the .service file (but ideally 
doesn't care about the file extension), but a .desktop file editor just 
won't work will it? - the .service file is like:

[D-BUS Service]
Name=org.gnome.Epiphany
Exec=/usr/bin/epiphany
User=hp # system bus feature davidz proposed

while the .desktop file is like:

[Desktop Entry]
Encoding=UTF-8
Name=Epiphany Web Browser
Name[langcode]=blah
GenericName=
Comment=
Exec=epiphany %U
StartupNotify=true
Terminal=false
Type=Application
Icon=web-browser.png
Categories=blah;baz;
MimeType=text/html;text/xml;

The only commonality I see is that they are in .ini syntax and both have 
a key called "Name" (in a different group).

I mean, there's nothing more in common here than between any two random 
XML files with different DTDs, right?

As a practical matter, dbus doesn't contain any code for the complex 
bits of .desktop files such as stripping % substitutions from Exec, or 
handling non-UTF-8 encoding.

> We are also discussing on xdg at lists.freedesktop.org using .desktop files 
> for program autostart (when the desktop starts).

That makes sense since the .desktop file describes a user-visible app, 
that people may want to drag into their autostart folder.

However, a .service may not be (and probably often isn't) user-visible. 
So for example I would not recommend showing all .service files in a GUI 
for editing what happens on startup. Certainly you don't want .service 
files in a menu editor.

> What I fail to see is why we should have a different format when there 
> already is one that suffices.

It's not a different _format_ (as in syntax/well-formed), but it is a 
different _kind of file_ (as in schema/dtd).

Even if we stick both service info and menu item info in one .desktop 
file, it's going to be in two different groups, so the result is sort of 
like XML namespaces, not like merging the XML dtds.

> There's also the fact that the D-Bus service activation looks a lot like 
> the KDE service files: they are in $KDEDIRS/share/services (which is the 
> same as $XDG_DATA_DIRS/services in most cases), they are .desktop files 
> and they have some keys for finding plugins.
> 
> In the future, I'd like to suggest the [$i]-mode lockdown too.

OK, I'm not well-informed on either of these issues, but am willing to 
learn more.

I'm not clear on what merging .service and .desktop would mean as a 
practical matter. Does it mean we load the two from the same directory?

If we did put the [D-BUS Service] group from the .service file into a 
.desktop file in the menu hierarchy, would the session bus daemon need 
to parse all the .desktop files? Remember it isn't using the 
desktop-specific cache capabilities to do it, and has to do it on 
login... in addition to being less numerous, .service files lack 
translations and are thus a lot smaller.


Hmm - another relevant line of thought, I have been wanting to extend 
.desktop files with something like:

DBusName=org.gnome.Epiphany
DBusArgs=%U

where if the DBusName key is present, the owner of that name has to 
support an interface like org.freedesktop.Launchable that can be used to 
run the application with the given DBusArgs. This could (maybe) make 
opening a new window in an already-running app an instantaneous 
operation, instead of forking a new process that does a bunch of 
initialization and connects to dbus only to hand off to the old process.

Havoc