ubuntu-phone team mailing list archive

[Gerry Boland <gerry.boland@xxxxxxxxxxxxx>]

On 13/11/13 13:26, Thomas Voß wrote:
> 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.

This is my favoured approach. It should be relatively quick to wrap for
Qt usage, and works with everything 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).

Sadly yeah, I have to agree. The KDE Frameworks 5 will modularize their
huge library greatly, but it's simply not ready yet.

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

Ah, news to me. Yep I'd found it from Razor-Qt, it appears to have a
bunch of XDG utility libraries written in Qt, which I've kept an eye on.

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

Yep, developing something upstream would be a good option. Having our
own implementation that isn't used by others is a bad solution. I'd much
rather sharing something with several other projects.


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

+1. If we're going to share API, why not share the code too.

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

GDesktopAppInfo is in libgio-2.0.so, which is an unpleasant 1.4MB in
size on my laptop. However the Unity Application plugin already pulls it
in. So we're not loosing anything really.
-G