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