libxdg

[David Faure]

On Tuesday 22 May 2012 18:07:50 DAV wrote:
> Also there is online Doxygen documentation (a bit outdated, though):
> http://vilkov.github.com/libxdg.

This starts with "This library is a fork of the official freedesktop.org library 
xdgmime". This is not the case anymore, is it? In fact, is there any code from 
xdgmime? I hope not, since it's GPL, and your code is LGPL.

I also have a number of questions about the on-disk cache:

> * List of XdgFileWatcher structures

Can you explain what these are for? Each path, in that list, is that a cache 
file or a desktop file, or a directory of desktop files?

But more generally, could we get rid of the whole idea of file watching, and 
just mandate that when someone installs a .desktop file, they must run update-
applications-cache, just like we do with mimetypes and update-mime-database?

> AVL tree of all ".desktop" files located in the same directory as cache file.

... and sub-directories, surely.

> Each key of this tree is a name of ".desktop" file (e.g. kde4-kate.desktop).

Is it? Looking at the cache file, I see full paths rather. I think relative 
paths might be better (shorter), but I actually don't have a strong opinion 
about this at this point. In any case, the docu should match reality, or vice 
versa ;)

> Each value of this tree is an AVL tree of groups, which in turns is an AVL 
> tree of entries.

Ah, heh, took me a long time to understand this. OK, this is the full contents 
of the desktop file itself, as a tree. Maybe simply add a typical example here.

(I first thought that "group" was a group of applications, as in the menu spec, 
but of course this is unrelated to this stuff).

> AVL tree of associations of mime type with ".desktop" files. 
> Each key of this tree is a name of a mime type (e.g. text). 

"text" is not the name of a mime type. "text/html" is. Is there any reason for 
splitting text/html into two leaves in the tree? Is this for supporting 
mimetypes like text/* or image/*? Hmm, why not. But otherwise it's a bit 
pointless and confusing.

> Each value of this tree is an AVL tree of sub types (e.g. html), which 
> contains a list of pointers to XdgApp structures.

What does this structure contain? The full contents of the desktop file, again? 
Or do I misunderstand that?
Surely there's no need to duplicate the contents again, for each mimetype 
associated with the application. Wouldn't it be enough to write in this tree, 
the name of the desktop file, in order to then look it up in the other tree if 
one wants to get more details about it?
Or is this space-optimized anyway, by pointing to the same data in the on-disk 
cache?
Please tell me more about what this tree contains, the documentation is 
confusing, my talking about structures here, but not in the first tree, but 
they seem quite similar.

> Note: Global version of this tree is used to resolve ".desktop" files
> according to the given mime type.

?? What's Global version? The one in /usr? Why is it special? Surely desktop 
files in $XDG_DATA_HOME can mention mimetypes too.
I'm not sure what you call resolving, here, in any case.

> AVL tree of all ".list" files located in the same directory as cache file. 

The typical use case for all this, is "what are the apps associated with a 
given mimetype, sorted by user preference", right?
With a tree for the associations coming from desktop files, and another tree 
for the contents of defaults.list/mimeapps.list, one has to look up into 
multiple trees to be able to answer that question. Wouldn't it be faster, and 
simpler (higher level) to have a single tree, combining these two?
I.e. a simple tree with
  key = mimetype -> value = list of desktop files
("merging" .list files into the desktop files) would give an immediate result,
compared to three lookups (initial list, then added associations, then removed 
associations), all this multiplied by the number of paths in XDG_DATA_DIRS 
plus one local dir, of course.
Do you think this could be done? Or am I overlooking some difficulty here?

Thanks,

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5