OLPC and .service files in a users home directory

[uwesmail2005-lkml at yahoo.de]

--- Havoc Pennington <hp at redhat.com> schrieb:

> 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).
And "Exec". Which are mostly the keys touched by so called
.desktop editors.
> 
> 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.
And when I have a process, that I know starts on startup, but can't
find in the startup editor I will think something fishy is going on
when it's nothing more than a service. I think we don't want the
numerous autostart mechanisms from windows where some program could
hide it's autostart in the wood of mechanisms and evade any attempt
to block it by the simple non-availability of a suitable editor.
> 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
Surely you mean "DBusName=/org/gnome/Application at org.gnome.Epiphany"!
Bus names don't have interfaces.
> 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
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
> 



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de