>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
Well , Rusty, Thanks for your comments. So here's my consideration:
Yes, Thanks for James's remind, I read the discussion between Horace and Robert
by checking the mail-list archive ( haven't join Intel at that time :), I can
see that we don't reach a agreement on where the desktop file management should
go to yet. I check with Horace, He told me the same thing as on the mail list :
the libgmenu is slow since it need to check all the keys required by the
desktop spec. However, we might just need to fetch very few of them, so we can
do it better.
On this aspect, I hadn't got time to verify it, but let's just believe what
Horace had said. So for this part, I did not update on the design document, But
I know that will be the concern, so I try to bring it up by sending the design
doc.
For me, I really don't care who should do the desktop info retrieve work, I
just want to make it work. So I check with Robert on what's already done in our
new UI design's app launcher. If it's proved that libgmenu can do better and is
well fit in our design, why not use it.
But, Still, I am wondering, should the app launcher or genesis maintain the
database. I don't think only app launcher will need these information. There
can be other apps would like to use these information. Sure, they can also IPC
app launcher, but say, If the final integrator or design house want to
implement their own app launcher?
Well there will be ipc overload if only app launcher is using genesis. But even
under this situation, the data need to be transferred is not big, and only one
time for starting up, the other time , the ipc data is just 0.x Kbytes. Why
wouldn't we keep this database in a lower level to gain more feasibility?
OK, for the second part, I will answer in rob's thread.
_______________________________________________
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
