ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On Wednesday 13 November 2013 10:01:24 you wrote:
> 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'm not saying that this is a complex task. Still I think we don't need yet 
another lib. And this would give a perfect chance to actually do what we tell 
people we do: Collaborate with others.

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

My opinion on this is:

Qt is really different to C++ (even though you can use everything from C++). It 
changes the language in a way that it is easy to learn and easy to use. 
Really, it doesn't look like C++ at all if you write Qtish code. Now, what we 
always do is to create some low level c API because we might want to have some 
python or vala binding at some point. Or we take an existing GObject api and 
just expose that somehow to the Qt world without paying attention if the API 
actually fits into the Qt ecosystem.

This is exactly the reason why our app developers are afraid of Qt. They don't 
even look at it because it's C++. And if I look at the stuff we provide along 
to the upstream Qt APIs I'm not surprised. It makes you deal with low level c 
stuff like callback pointers, memory management and everything all over. At the 
same time we just leave existing easy to use Qt APIs broken and unsupported 
just because, well, it wasn't rocket science to come up with something 
ourselves or there was some gtk lib we already knew. We keep on dropping Qt 
apis in favor of some hard to use mix between low level c, gobject and Qt.

Coming from the Qt world I'm obviously somewhat biased towards this topic too. 
But I just see our Qt api's very fragmented and badly supported and this 
discussion is one good example why. I really think we should adapt more to the 
existing Qt world given that we chose Qt as the main developer offering. And 
really try to reuse existing things instead of always coming up with something 
new ourselves.

As long as we want community people to develop for us we should make it easy 
for them and think about portability. One big strength of Qt is that we can 
easily port stuff from KDE, MeeGo, Jolla and Blackberry. Lets not ruin this 
with coming up with something new on every second line of code, especially 
when there is ready to use Qt stuff available.

Br,
Michael

> 
> 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-GAppInf
> >> > o.h
> >> > tml [3]
> >> > http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc
> >> > 218
> >> > 8bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkc
> >> > onf
> >> > ig%2Fsrc%2Fcore [4]
> >> > https://github.com/hawaii-desktop/qtxdg/blob/master/src/xdg/qdesktopfil
> >> > e.h
> >> > [5] https://github.com/desrt/desktop-file-index
> >> > [6]
> >> > https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/1
> >> > 796
> >> > 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