faure at kde.org
Tue May 22 09:20:57 PDT 2012
On Tuesday 22 May 2012 18:07:50 DAV wrote:
> Also there is online Doxygen documentation (a bit outdated, though):
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
> 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
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?
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
More information about the xdg