ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

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.