ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part