On Wed, 2008-11-05 at 19:29 -0700, Liu, Raymond wrote:
> Hi guys
>
> This is Raymond
> I have worked with Horace to develop genesis (The application life-cycle
> manager) for the past several weeks.
>
> Base on one of our targets on genesis (act as a center entrance for multiple
> invokers with easy access) I have added the Dbus interface support to
> genesis. So that, with a daemon running in the backstage, every one can
> retrieve information about the existing applications, get the changing
> notification and launch it through dbus interface very easily.
>
> In fact, to make the things even easier, I have wrapped the dbus interface
> handling functions with normal functions calls in the genesis library. So
> that the user might even not knowing that they are actually using the dbus
> interface. You can check the sample code in the test dir.
>
> Of course, If you prefer, you can just using the cmdline tools dbus-send to
> do these things without a single line of coding.
>
> And Also I have updated the design documents as attached here.
> In it, I have added the dbus interface and plan to remove the splash feature.
> If any one have any comments please let me know
>
> And for the next version, I am considering to extend the life-cycle manager's
> concept from the launching time-span to the whole life-span from the app is
> installed on the device, by doing something like collect statistics data on
> launching counts and running times, with these information user can find out
> which app is frequently used and sort the lists or highlight/hide some apps
> according to it etc. If anyone has any ideas on this field, please also do
> let me know 8)
>
> You can got the latest code with: git clone
> http://git.moblin.org/repos/users/raymond/genesis.git
I think your introduction does a good job of stating what you plan on
doing, so for the benefit of everyone else...
<Introduction>
Application life-cycle manager, codename Genesis, is part of the Moblin
application framework, exposing interface for application developers to
conveniently access application information, starting an application by
calling a single API, and processing various run-time statuses for each
running application.
It also maintains the application list for the applications that are
installed in the system, and updates the list whenever a change happens
in the monitored applications.
The purpose of the application life cycle management project is twofold:
Provide a set of utility functions, for applications on the platform, to
quickly and easily walk through the desktop files on a standard Linux
system, to expose applications and their categories.
Provide a mechanism for launching applications and tracking the
execution of those applications to watch for resource starvation, hangs,
unresponsiveness, etc.
</Introduction>
Now this leads me to my consern...
In the past (back when Horace was driving this design), there was
feedback from our new UI developers that libgmenu provided everything
they needed to implement the UI shell (i.e. the thing that launches apps
and allows a user to switch between running apps). This would be half of
the above intent documented above:
<snip>
Provide a set of utility functions, for applications on the platform, to
quickly and easily walk through the desktop files on a standard Linux
system, to expose applications and their categories.
</snip>
I don't see anything in your design document that explains why we need
to duplicate (and extend) the existing libgmenu functionality.
Why not limit the scope of genesis to the second part of your
introduction?
--rusty
_______________________________________________
Moblin dev Mailing List
[email protected]
To manage or unsubscribe from this mailing list visit:
https://lists.moblin.org/mailman/listinfo/dev or your user account on
http://moblin.org once logged in.
For more information on the Moblin Developer Mailing lists visit:
http://moblin.org/community/mailing-lists
