ubuntu-phone team mailing list archive

[Albert Astals Cid <albert.astals@xxxxxxxxxxxxx>]

On Wednesday 13 November 2013 14:27:19 Alberto Mardegan 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).

Does QSettings support "Localized values for keys" [1]? 

Cheers,
  Albert

[1] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#localized-keys

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