On Thu, 2014-04-17 at 11:09 -0400, Rodney Dawes wrote: > On Thu, 2014-04-17 at 09:52 -0500, Ted Gould wrote: > > On Wed, 2014-04-16 at 14:10 -0400, Rodney Dawes wrote: > > > On Wed, 2014-04-16 at 19:11 +0200, Martin Pitt wrote: > > > > Rodney Dawes [2014-04-16 13:02 -0400]: > > > > > We're talking about one app loading the translations for all apps. > > > > > > > > FWIW, that might be too slow regardless of which approach we use. > > > > That's fairly similar to what gnome-menus did back then to read all > > > > the *.desktop files in the system to build the start menu. We've had a > > > > patch there which created a cache of all available translations which > > > > got updated automatically via a dpkg trigger whenever there was a > > > > change in /usr/share/applications. If even parsing 200 ini files takes > > > > too long for a fluid UI experience, this might be something to consider. > > > > > > A cache might help, but I'm not sure it would be the best solution. It > > > would have to be a bit more complex than just the translations. > > > > For me I can't figure out why the click scope would be reading the > > desktop files of click apps anyway, it should be building a cache when > > the app is installed. We have good hooks for that now. It could also > > rebuild the cache when the language is changed. Both of those are > > significantly more rare conditions than searching for applications. > > Also, the cache can be built with the names already tokenized and > > optimized for search as well. > > The click scope doesn't install things, and click isn't building the > necessary cache anywhere. The scope can't build either of those (unless > it's going to read the desktop files, in which case it would have to > read them every time anyway to make sure they are in the cache), because > the scope is stateless. The scope may not even be running when an app is > installed. There would have to be an external tool to build such a > cache, regardless of what the cache contains.
Correct, that external tool would be a click hook that the click scope would install. Basically similar to the hook that UAL installs today. The architecture would be similar to how URL dispatcher does things: http://ubuntuone.com/6qz6zWRZXfsW8v9RyeNGmG ¹ Basically there's a click hook that updates the cache when applications are installed and an Upstart job that runs at startup to catch any new system application changes. Ted ¹ http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.14.04/view/head:/docs/URL%20Dispatcher%20Architecture.svg
signature.asc
Description: This is a digitally signed message part
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
