On Mon, 2005-07-04 at 11:27 +0200, Waldo Bastian wrote: > On Saturday 02 July 2005 18:14, John (J5) Palmieri wrote > > > > Hey Waldo, > > > > I would like a brief overview of what KDE does. > > * Dependency handling wrt other autostart services to ensure a specific > startup order (e.g. start panel before starting panel applet) This requires a > definition of when a service is finished starting up.
We use D-Bus for this and a ServiceStarted signal. Startup notification could be used in the simple case. Of course at that point we need to specify naming. We use D-Bus names (e.g. org.gnome.Panel). > * Conditional autostart: start is dependent on the value of a specified > boolean configuration key. This is hard to standardize though, as long as > there isn't a common configuration system. Could be a new key in the ,desktop file. I think we use enable=(TRUE| FALSE) may want to add DEFAULT to take DE setting. > * Whether to start the service before or after (xsm style) session > restoration. Is this important? Could we somehow use dependencies to do this instead of a separate config? > > Here is where I see we > > should start: > > > > - Agree upon a user directory where we can drop desktop files into for > > starting up upon login. This should be desktop independent and not > > contain desktop dependent services as of yet (i.e. desktops should not > > use this as their service starting framework, it should be for the user > > only). If a service is required for the desktop it shouldn't be user > > visible anyway. > > Ok. > > > - Questions raised: should we have a system wide directory where > > third parties can drop desktop files where their RPM/DEB/etc. is > > installed? > > Yes, I would think so. > > > - Agree upon a wrapper executable name and command line switches. We > > need a wrapper to make things simpler when working with d-bus. This is > > a forward looking requirement for when there is a full service > > framework. Having a common wrapper interface allows services to be > > integrated into a desktop's framework without the service having to know > > anything about that framework. The wrapper is the liaison, knowing how > > to talk with the system and exec the service. > > I'm not sure I follow this, to what extent is a .desktop file with a Exec= > line not sufficient? Or do you mean that you want a wrapper executable to > access dbus service activation? Yes, the wrapper allows activation without having to add an activation file somewhere. It also allows a non-dbus aware services to still be managed through our service manager (of course the wrapper falls short for services that fork and exit the main process). The main point of standardization here is for third parties who want to install their stuff and have it work on all desktops. The wrapper would allow us to give them that ability while still integrating with the service framework without having to know a bit about it. We could punt this issue for now but just wanted to throw it out there as part of what we are doing for GNOME. -- John (J5) Palmieri <[EMAIL PROTECTED]> _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
