ubuntu-phone team mailing list archive

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

On Wed, Nov 13, 2013 at 1:27 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> On 11/12/2013 04:56 PM, Gerry Boland wrote:
>> 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.
>
> I would like to highlight the "as much as possible": until we don't have
> a single programming language/toolkit, we don't need a single
> implementation. To clarify:
>
>> 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.
>
> This will be developed regardless of our involvement, and it's the only
> API which will be usable from Vala. Vala applications already depend on
> GObject and GIO, so as long as we support Vala it doesn't make sense to
> come up with a different implementation, and this will be in our archive
> anyway.
>
> I think the question is whether we want to wrap it into a Qt API, or
> using something else.
>
>> 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.
>
> Despite my desire to collaborate with KDE as much as possible, I don't
> think that this, in its current implementation, is usable for us. It's
> too bloated :-)  It reimplements the whole parsing (which we already
> have in QSettings) and in practice the benefits it brings over QSettings
> are minimal (a few APIs which would be trivial to implement with QSettings).
>
>> 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.
>
> It seems the author dropped this in favor of KConfig (the link is no
> longer valid).
> However, razor-qt/LXDE is still using it:
> https://github.com/Razor-qt/razor-qt/tree/master/libraries/qtxdg
>
>> 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?
>
> I think that, at least for now, the API is more important than the
> implementation. I'd like to see us agreeing with KDE and Razor-qt over a
> Qt API (at first sight, the one used by razor-qt looks good enough).

I think your assumption that a Qt API is sufficient is slightly
biased. If we start investing time and effort here, we should make
sure that our use-cases are covered. That being said, I don't see any
particular reason why we shouldn't agree on the full stack with KDE
and razor-qt and we share the burden of implementing and maintaining
it instead of defining an API, coming up with one implementation,
testing and maintaining it, to ultimately diverge from the pre-defined
API as it does not fit anymore. I don't see the benefit here.

> We could create a common project, where we have the header files in one
> common folder, and (possibly) different directories for the
> implementation, and the one to be used is chosen at build time (so no
> one cares if the other one breaks something in his own implementation).
> This would effectively guarantee that the API will stay the same.
>

See my remark before, what do we gain?

> As to the implementation, I would initially go with wrapping
> GDesktopAppInfo, because that would quickly bring us to a complete
> implementation. We can then replace it with something else, if we want to.
>

Which pulls in a bunch of dependencies that we do not need. Not a fan
of this approach.

Cheers,

  Thomas

> Ciao,
>   Alberto
>
> --
> 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