ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Wed, Nov 13, 2013 at 9:30 AM, Michael Zanetti
<michael.zanetti@xxxxxxxxxxxxx> wrote:
> 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.

Okay, let's clarify the problem "complexity" here:

  (1.) We need to parse a very simple text file format that is well-spec'd.
  (2.) Value types are constraint and well-defined:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
  (3.) Keys are simple strings that don't need further interpretation.

Just parsing and validating this data, exposing well-known, default
keys and making that accessible to any sort of toolkit is really
simple. Please point out places where I'm oversimplifying the problem,
but I think this is really simple to implement and expose via an API.
A second step then would be toolkit-specific APIs, including toolkit
specific types and so on. But that toolkit-specific API is a second
layer from my POV.

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.
>

Well, we need to consume desktop file entries from Vala, too, as per
Gerry's list.

Thanks,

  Thomas

> 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
>
>
> --
> 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