On Wed, Nov 13, 2013 at 1:27 PM, Alberto Mardegan <alberto.marde...@canonical.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- 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