On Sunday 15 January 2012 17:40:27 DAV wrote: > I added missing features: > - C-implementation of AVL trees; > - indexed (by using of AVL trees) access to all ".desktop" files and its > contents (implementation of "Desktop Entry Specification");
Hello Dmitriy, Sorry for not replying to your earlier private email about this. But let's discuss this here, it's a better idea indeed. I'm very excited by the idea of having a cross-desktop solution to the very common issue of getting the list of apps associated with a given mimetype, I've been thinking that we need that, for quite some time (when I saw your mail, I thought "wow, it's Christmas!"). (We use ksycoca in kde4 for this purpose, but I'd like to get rid of it for kde5, so the timing is perfect.) I have one major issue with the implementation you're suggesting though. Unlike the mimetype stuff which is based on a mmap'ed cached (mime.cache), it seems to parse all the .desktop files in-process. This means, if you start 10 apps and they all need at some point to use xdg_mime_*_apps_lookup, they will each suffer the runtime penalty (slowness and memory usage) of parsing all the .desktop files on the system. We don't do that with mimetypes: shared-mime-info has a binary called "update- mime-database" which does the collecting and parsing of the (mime) files, and generates a binary file called mime.cache, whose on-disk layout is such that it can be used via mmap. This way, the applications are fast. So for application .desktop files, we could have another helper binary, say update-app-database (part of shared-mime-info maybe, so that we don't need to depend on xdgmime, which we don't use in KDE and I think gnome might not either, or in a new module), which updates a new cache, say "application.cache" in a given directory. RPMs and other packages would run that script when installing .desktop files, and then xdgmime could just mmap that and look things up directly, without the need to parse any .desktop files during the application runtime. Now if you implemented that, it would definitely be the best Christmas ever, in my eyes :-) Alex, Bastien: do you agree about the approach? Would gnome/gtk/glib use it, if it was done that way? (Otherwise half the RPMs/DEBs in the world will forget to run the update-app-database... so to me this solution will only work out in practice if it's used by everyone.) > const XdgArray *xdg_mime_default_apps_lookup(const char *mimeType); > const XdgArray *xdg_mime_user_apps_lookup(const char *mimeType); > const XdgArray *xdg_mime_known_apps_lookup(const char *mimeType); A bit of documentation wouldn't hurt ;-) What's each of those doing exactly? It seems user_apps looks at the contents of mimeapps.list (but allows any *.list file? Is that in the spec?), but it only looks at [Added Associations], so this is missing support for [Removed Associations]. I think "user apps" should return the final set: default apps plus those added by the user, minus those removed by user. That's what client code cares mostly about. There's also the issue that the defaults should be desktop-dependent, but that's an entire new topic. The current situation is that KDE uses InitialPreference in the desktop files while Gnome uses a defaults.list file (iirc). One could say it sucks that this is non-standard, but on the other hand it gives "defaults are desktop-dependent" de facto. If we were to use a common way (which would definitely please distros and ISVs), then we would still need a way to make the defaults desktop-dependent, I would think, somehow (maybe a *.list file per desktop). (Although I definitely prefer the more modular KDE solution where an app can be installed later on and not have to hack into a global file to take precedence). I'm sure we've had this discussion already on this list, but I forgot the outcome of it :-} > - indexed (by using of AVL trees) access to icon themes and its contents > (implemetation of " > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > " and > " > http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.ht > ml "). My first reaction was: this, too, only seems interesting to me if it's based on a mmap'ed binary cache. Otherwise apps can just look things up directly on disk, as they already do currently. But either it only caches the contents of the theme files, and then it seems not so useful (there are only very few of them, typically, right?), or it also caches the names of all available icons, but that might not be a big saving compared to looking up in the file system directly. So overall, I'm not sure what this would be fixing, apart from the lack of an icon spec implementation at that level of the stack. There's already one in KDE, one in Qt, and surely a few in the gnome/glib/gtk world, but I suppose none of this fits your bill otherwise you wouldn't have written it :-) Anyhow, no real objection from me, but the target audience probably needs to be defined, and like xdgmime itself (AFAIK), I think it wouldn't be much used. -- David Faure, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
