ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On Tuesday 12 November 2013 16:15:45 Thomas Voß wrote:
> On Tue, Nov 12, 2013 at 3:56 PM, Gerry Boland
> 
> <gerry.boland@xxxxxxxxxxxxx> wrote:
> > Hi folks,
> > Ryan Lortie and Lars Ubernickel were at this years FreeDesktop Summit
> > [1]. One thing they've mentioned to me is the fact that it was decided
> > to have a binary cache of desktop files, to improve access and searching
> > of that data.
> > 
> > This reminded me that our desktop file parsing situation is a bit of a
> > mess. Right now we have multiple approaches:
> > - unity (Qt) launcher uses QSettings ini file parser [should be standard
> > compliant]
> > - unity-mir/qtubuntu (Qt) has it's own super-basic parser, which needs
> > to be replaced
> > - upstart-app-launch (bash/C) has a tiny C util to read the "Exec"
> > strong from a desktop file
> > - click lenses (Vala) use GLib.KeyFile, another ini file parser
> > [standard compliant]
> > and there's probably more. Since we use many GTK-based tools,
> > GDesktopAppInfo is often used too.
> > 
> > The cache is generated by the tool that can be found at [5].
> > 
> > The main point of the cache is answering complex questions like "give me
> > the apps associated with application/pdf", though it will also probably
> > speed up single .desktop-file key-value data reads since the cache will
> > most probably be kept in memory or disk cache.
> > 
> > A desktop file reader could benefit if it supports this new cache. So
> > having a custom parser, or just using ini file parsers, would not ideal
> > if we want to use this cache in future.
> 
> What is the underlying technology used for the cache and how will it
> be exposed to the rest of the system?
> 
> > I think a logical approach is to standardize (as much as possible) on a
> > single desktop file parser implementation ASAP. Should we later want to
> > use the cache, we can add it to our chosen parser, and thus all its
> > users will immediately benefit.
> 
> If we want to standardize, I would propose to look at the
> implementation that is the most toolkit-/runtime-agnostic one, with
> the fewest dependencies to make sure that higher levels of the stack
> can easily consume it. Ideally something with a very simple API (and
> desktop file parsing is not rocket science, so it should be fairly
> small).

I think being the most toolkit-agnostic one and having a very simple api 
doesn't really fit together. I do agree that we shouldn't pull in lots of 
dependencies for this, but given that we use Qt in all the places we consume 
it, makes it seem like a good idea to at least look at the existing Qt 
implementations before coming up with something ourselves.

Br,
Michael

> 
> Thomas
> 
> > Here are possible solutions:
> > 
> > 1. GDesktopAppInfo [2]
> > - will support the new cache shortly.
> > - we would need to wrap this for easy use with Qt however.
> > - pulls in GIO
> > - usable though Vala too.
> > - it will be well tested and used by more than just us.
> > 
> > 2. KDE frameworks 5 [3]
> > - cache support not landed yet.
> > - whole framework is not released and thus not packaged for Ubuntu. We
> > would have to help the KDE guys out on this.
> > - would integrate nicely with Qt.
> > - will be well tested with many users aside from us.
> > - not usable with Vala.
> > 
> > 3. QtXDG [4]
> > - no plans to support cache currently. Would need extending to support
> > the cache.
> > - packaged for Ubuntu, but Qt4 only. It does build and work on Qt5
> > however. Would need the Qt5 version to be packaged.
> > - integrates nicely with Qt.
> > - not many users, nor well tested.
> > - not usable with Vala.
> > 
> > 4. Make something home-grown
> > - Antii Kaijanmäki has written a desktop file parser in Qt5 [6]. It
> > would need to be split into a separate library, and be packaged.
> > - no plans to support cache currently.
> > - integrates nicely with Qt.
> > - We would be the sole users, and this having less "in the wild" testing.
> > - not usable with Vala, without significant changes.
> > 
> > What do people think? Are there alternatives I'm missing?
> > Thanks
> > -Gerry
> > 
> > 
> > 
> > 
> > [1] https://en.opensuse.org/openSUSE:2013_Desktop_Summit#Agenda
> > [2]
> > https://developer.gnome.org/gio/unstable/gio-Desktop-file-based-GAppInfo.h
> > tml [3]
> > http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc218
> > 8bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkconf
> > ig%2Fsrc%2Fcore [4]
> > https://github.com/hawaii-desktop/qtxdg/blob/master/src/xdg/qdesktopfile.h
> > [5] https://github.com/desrt/desktop-file-index
> > [6]
> > https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/1796
> > 63
> > 
> > --
> > Mailing list: https://launchpad.net/~ubuntu-phone
> > Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ubuntu-phone
> > More help   : https://help.launchpad.net/ListHelp