On Wed, Nov 13, 2013 at 9:30 AM, Michael Zanetti <[email protected]> wrote: > On Tuesday 12 November 2013 16:15:45 Thomas Voß wrote: >> On Tue, Nov 12, 2013 at 3:56 PM, Gerry Boland >> >> <[email protected]> wrote: >> > Hi folks, >> > Ryan Lortie and Lars Ubernickel were at this years FreeDesktop Summit >> > [1]. One thing they've mentioned to me is the fact that it was decided >> > to have a binary cache of desktop files, to improve access and searching >> > of that data. >> > >> > This reminded me that our desktop file parsing situation is a bit of a >> > mess. Right now we have multiple approaches: >> > - unity (Qt) launcher uses QSettings ini file parser [should be standard >> > compliant] >> > - unity-mir/qtubuntu (Qt) has it's own super-basic parser, which needs >> > to be replaced >> > - upstart-app-launch (bash/C) has a tiny C util to read the "Exec" >> > strong from a desktop file >> > - click lenses (Vala) use GLib.KeyFile, another ini file parser >> > [standard compliant] >> > and there's probably more. Since we use many GTK-based tools, >> > GDesktopAppInfo is often used too. >> > >> > The cache is generated by the tool that can be found at [5]. >> > >> > The main point of the cache is answering complex questions like "give me >> > the apps associated with application/pdf", though it will also probably >> > speed up single .desktop-file key-value data reads since the cache will >> > most probably be kept in memory or disk cache. >> > >> > A desktop file reader could benefit if it supports this new cache. So >> > having a custom parser, or just using ini file parsers, would not ideal >> > if we want to use this cache in future. >> >> What is the underlying technology used for the cache and how will it >> be exposed to the rest of the system? >> >> > 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. >> >> If we want to standardize, I would propose to look at the >> implementation that is the most toolkit-/runtime-agnostic one, with >> the fewest dependencies to make sure that higher levels of the stack >> can easily consume it. Ideally something with a very simple API (and >> desktop file parsing is not rocket science, so it should be fairly >> small). > > I think being the most toolkit-agnostic one and having a very simple api > doesn't really fit together.
Okay, let's clarify the problem "complexity" here: (1.) We need to parse a very simple text file format that is well-spec'd. (2.) Value types are constraint and well-defined: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html (3.) Keys are simple strings that don't need further interpretation. Just parsing and validating this data, exposing well-known, default keys and making that accessible to any sort of toolkit is really simple. Please point out places where I'm oversimplifying the problem, but I think this is really simple to implement and expose via an API. A second step then would be toolkit-specific APIs, including toolkit specific types and so on. But that toolkit-specific API is a second layer from my POV. I do agree that we shouldn't pull in lots of > dependencies for this, but given that we use Qt in all the places we consume > it, makes it seem like a good idea to at least look at the existing Qt > implementations before coming up with something ourselves. > Well, we need to consume desktop file entries from Vala, too, as per Gerry's list. Thanks, Thomas > Br, > Michael > >> >> Thomas >> >> > 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. >> > >> > 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. >> > >> > 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. >> > >> > 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? >> > Thanks >> > -Gerry >> > >> > >> > >> > >> > [1] https://en.opensuse.org/openSUSE:2013_Desktop_Summit#Agenda >> > [2] >> > https://developer.gnome.org/gio/unstable/gio-Desktop-file-based-GAppInfo.h >> > tml [3] >> > http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc218 >> > 8bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkconf >> > ig%2Fsrc%2Fcore [4] >> > https://github.com/hawaii-desktop/qtxdg/blob/master/src/xdg/qdesktopfile.h >> > [5] https://github.com/desrt/desktop-file-index >> > [6] >> > https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/1796 >> > 63 >> > >> > -- >> > Mailing list: https://launchpad.net/~ubuntu-phone >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~ubuntu-phone >> > More help : https://help.launchpad.net/ListHelp > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
