xdgmime

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5