ubuntu-phone team mailing list archive

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

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

Oh, I'm totally aligned with that and I'm actually proposing to unify
the parsing across toolkits as much as possible by means of a simple,
well-tested low-level library that does exactly that.

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

True, that's why I think collaboration is necessary to make code reusable.

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

Not entirely sure where that happened before tbh.

One thing we have to keep in mind is that our ecosystem is not Qt/QML
only, but also consists of HTML5/JS and Go is in the pipeline to
become a first class citizen, too. On top, we need to make integration
of different runtimes as easy as possible to ease porting of e.g. game
engines. While I do agree that toolkit-specific APIs are required,
too, we as platform maintainers need to make sure that different
runtimes/toolkits can easily leverage our platform offerings. For
that, I'm proposing a layered approach that offers a low-level
reference implementation meant to be consumed by toolkits and
runtimes.

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

Do you have an example handy where our Qt APIs are fragmented?

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

Again, not saying that. On top, people who are for example familiar
with Blackberry will find the layered approach really really familiar.

Thomas

> 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