ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Thu, 2014-04-17 at 10:26 -0500, Ted Gould wrote:
> 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:

Well, it would be the hook, and the tool that the hook runs and actually
does the parsing and cache generation, a la update-desktop-database
being run in a dpkg trigger. But sure, that's a possibility, assuming
that cache is the right solution to the problem.

I don't want to implement caching to work around problems in the scopes
architecture and the way the dash UI works. For example, the only way to
"move" an app from the "available" category to the "installed" category,
is to re-do the search, right now. But a cache is a workaround for that,
not a solution to the problem. I'm also not sure the QML for the UI is
even capable of handling something like a move right now.

The cache also doesn't solve the problem of deciding whether to use
inline translations in .desktop files, or to use .mo files for the
translations. All it does is move the parsing to another point in time.
The performance and battery usage concerns still remain. Even with a
cache, we don't want the thing building the cache to have to load all
the .desktop files, and all the .mo files, to do it, I don't think.
Having inlined translations in the .desktop files will still be a bigger
win there.