Rob, thanks a lot for giving out your comments and suggestions. I have once used gnome-menus interface to read through all of the desktop files and extract the contents of them before, but gnome-menus interface seems to have a slow performance on Atom based platform that it take a really long time to go throught the desktop files and read out information in them. Therefore, I wrote the desktop file parse functions in genesis to speed up loading desktop file information.
And in current Moblin 2.0 application framework, some general components in desktop might also call Genesis to acquire desktop file information, besides App launcher. A good example is the four corner plugin that will set up four quick launch button at the four corners of screen, project link is http://test.moblin.org/projects/moblin-compiz-plugins. Generally, application itself will seldom need Genesis. Another feature that Genesis covers is to have quick start up response by poping up splash screen or a loading banner before main application window showing up. In that case, it is also necessary to maintain an application list with its splash screen information. I will definitely think of your suggestions and we do consider of putting our focus on managing application life cycle instead of parsing desktop info, and thanks for sharing startup-notification and libtaku, I will take a look on them. Regards, Horace -----Original Message----- From: Rob Bradford [mailto:[EMAIL PROTECTED] Sent: 2008年9月2日 19:43 To: Li, Horace Cc: [email protected] Subject: Re: [Moblin Dev] Application life-cycle manager design doc draftis attached. On Mon, 2008-09-01 at 23:48 +0800, Li, Horace wrote: > Hi, All, > > I completed a design document draft of application life-cycle manager, > codename Genesis. Application life-cycle manager is part of application > framework in Moblin 2.0 software stack, and you could find more detailed > description in the document. > > Please help to review the document and see if the information included > in the document is adequate and clear. Any comments are welcome. > > Application life-cycle manager project is currently available at > http://test.moblin.org/projects/genesis-application-lifecycle-manager. > This looks very interesting and i've been browsing through the code that you've written. Most of these comments relate to the desktop file stuff rather than life cycle management Did you look into gnome-menus which is an existing implementation for dealing with FDO .desktop files: http://svn.gnome.org/svn/gnome-menus/trunk/ The main header file is here: http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/gmenu-tree.h?revision=876&view=markup It has support for a lot of the things that you seem to need including monitoring, etc. (If this is too heavy then you might want to take a look at: http://svn.o-hand.com/repos/matchbox/trunk/matchbox-desktop-2/libtaku/) I'd be concerned about having a central daemon that loads in the desktop files, parses them and then communicates with the details to a client. I can only typically imagine that only one client (the launcher) will care about displaying available applications. If you have to have a copy of all the data in both the client and the daemon you've just wasted memory with the addition of e.g. rpc overhead. In a lot of ways the life-cycle management parts of genesis are similar to what a session manager, e.g. gnome-session will do, including respawning crashed components etc. The code for gnome-session has been recently reworked to simplify some aspects and it now features a dbus API for the management. An alternative strategy i'd like to suggest for genesis is to focus only on the launching and life cycle and that the api for client (i.e. launcher) would be a very simple "run this full path" command. The handling of the .desktop files would only be for the launcher to deal with. Also, just in case you don't know about it: you should care about interoperating with the startup-notification api: http://www.freedesktop.org/wiki/Software/startup-notification Lots of ideas for you. Good luck! Cheerio, Rob _______________________________________________ dev mailing list [email protected] https://www.moblin.org/mailman/listinfo/dev
