On Wed, Nov 13, 2013 at 11:19 AM, Michael Zanetti <michael.zane...@canonical.com> wrote: > On Wednesday 13 November 2013 10:01:24 you wrote: >> On Wed, Nov 13, 2013 at 9:30 AM, Michael Zanetti >> >> <michael.zane...@canonical.com> wrote: >> > On Tuesday 12 November 2013 16:15:45 Thomas Voß wrote: >> >> On Tue, Nov 12, 2013 at 3:56 PM, Gerry Boland >> >> >> >> <gerry.bol...@canonical.com> 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'm not saying that this is a complex task. Still I think we don't need yet > another lib. And this would give a perfect chance to actually do what we tell > people we do: Collaborate with others. >
Oh, I'm totally aligned with that and I'm actually proposing to unify the parsing across toolkits as much as possible by means of a simple, well-tested low-level library that does exactly that. >> >> 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. > > My opinion on this is: > > Qt is really different to C++ (even though you can use everything from C++). > It > changes the language in a way that it is easy to learn and easy to use. > Really, it doesn't look like C++ at all if you write Qtish code. Now, what we > always do is to create some low level c API because we might want to have some > python or vala binding at some point. Or we take an existing GObject api and > just expose that somehow to the Qt world without paying attention if the API > actually fits into the Qt ecosystem. > True, that's why I think collaboration is necessary to make code reusable. > This is exactly the reason why our app developers are afraid of Qt. They don't > even look at it because it's C++. And if I look at the stuff we provide along > to the upstream Qt APIs I'm not surprised. It makes you deal with low level c > stuff like callback pointers, memory management and everything all over. At > the > same time we just leave existing easy to use Qt APIs broken and unsupported > just because, well, it wasn't rocket science to come up with something > ourselves or there was some gtk lib we already knew. We keep on dropping Qt > apis in favor of some hard to use mix between low level c, gobject and Qt. > Not entirely sure where that happened before tbh. One thing we have to keep in mind is that our ecosystem is not Qt/QML only, but also consists of HTML5/JS and Go is in the pipeline to become a first class citizen, too. On top, we need to make integration of different runtimes as easy as possible to ease porting of e.g. game engines. While I do agree that toolkit-specific APIs are required, too, we as platform maintainers need to make sure that different runtimes/toolkits can easily leverage our platform offerings. For that, I'm proposing a layered approach that offers a low-level reference implementation meant to be consumed by toolkits and runtimes. > Coming from the Qt world I'm obviously somewhat biased towards this topic too. > But I just see our Qt api's very fragmented and badly supported and this > discussion is one good example why. I really think we should adapt more to the > existing Qt world given that we chose Qt as the main developer offering. And > really try to reuse existing things instead of always coming up with something > new ourselves. > Do you have an example handy where our Qt APIs are fragmented? > As long as we want community people to develop for us we should make it easy > for them and think about portability. One big strength of Qt is that we can > easily port stuff from KDE, MeeGo, Jolla and Blackberry. Lets not ruin this > with coming up with something new on every second line of code, especially > when there is ready to use Qt stuff available. > Again, not saying that. On top, people who are for example familiar with Blackberry will find the layered approach really really familiar. Thomas > Br, > Michael > >> >> 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-GAppInf >> >> > o.h >> >> > tml [3] >> >> > http://quickgit.kde.org/?p=kdelibs.git&a=tree&h=96b05b9b35e395ef2de16dc >> >> > 218 >> >> > 8bbfd8eb190de7&hb=c2e988586e7b8788030195dbec625a21c1dd03af&f=tier1%2Fkc >> >> > onf >> >> > ig%2Fsrc%2Fcore [4] >> >> > https://github.com/hawaii-desktop/qtxdg/blob/master/src/xdg/qdesktopfil >> >> > e.h >> >> > [5] https://github.com/desrt/desktop-file-index >> >> > [6] >> >> > https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/1 >> >> > 796 >> >> > 63 >> >> > >> >> > -- >> >> > 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 -- 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