OLPC and .service files in a users home directory
hp at redhat.com
Mon Oct 30 18:31:28 PST 2006
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:
User=hp # system bus feature davidz proposed
while the .desktop file is like:
Name=Epiphany Web Browser
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
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:
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.
More information about the dbus