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). 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.html > [3] > http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc2188bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkconfig%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/179663 > > -- > 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
