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 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp