ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

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

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.

Ciao,
  Alberto