On Sat, 2008-11-08 at 09:35 +0800, Liu, Raymond wrote: [snip] > 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.
If the only fault with libgmenu is that it's slow, could we not spend some time to profile and optimise it, working with the upstream maintainer, so we get the kind of response time we're after? Paul > 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 -- Intel Open Source Technology Centre http://oss.intel.com/ _______________________________________________ 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
