libxdg

[DAV]

Hi, all!

I finally did it :) I have update libxdg documentation:
 - here is the small Wiki with basic info about the library:
https://github.com/vilkov/libxdg/wiki
 - here is updated online Doxygen documentation:
http://vilkov.github.com/libxdg
 - and code itself: https://github.com/vilkov/libxdg

Could you possibly take a look at the documentation please, especially if
you are Stake Holder, like e.g. David :)
If there won't be suggestions, I will create a release tag (0.2)
at 19:00:00 Monday May 28, 2012 in GMT.

> > * 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?
It's just like you said - there is no any file watching facility. This
structures is used just
for checking validity of cache files.

> 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 will, but in the next release (after 0.2), because I'm in release rush
now (at my job).

> "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.
Hmm... It could be so, but the reason of this is performance. When we have
only tens of mime types it won't be a problem, but when we are speaking
about
thousands or even tens of thousands for each mime group/sub type
 (i.e. application/ text/ etc) it will be a serious problem.

> > 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.
Well as I mentioned before old documentation was a bit outdated and, lets
say,
didn't describe whole things clearly enough... I hope new one will.

> The typical use case for all this, is "what are the apps associated with a
> given mimetype, sorted by user preference", right?
Yes, it is.

> 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.
Everything just the way you describe it - the library returns merged
results from
all XDG_DATA_DIRS directories and local directory too. When one asks the
library
about, e.g. default associations the library returns a list of apps from
all ".list" files
(system-wide) there is no initial list and there is no need (and actually
possibility too)
to scan XDG_DATA_DIRS. All this implementation details (like XDG_DATA_DIRS
and
local dir) encapsulated in the library.

> Do you think this could be done? Or am I overlooking some difficulty here?
It could easily be done by adding one more function which will group the
results from
different groups ("Default Associations", "Added associations", etc).
By the way, this functionality is implemented in example in online
documentation.

--------------------------------
 Best regards, Dmitriy.



2012/5/23 David Faure <faure at kde.org>

> On Wednesday 23 May 2012 10:03:33 Sanel Zukan wrote:
> > > 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.
> >
> > Hm... isn't xdgmime under LGPL?
>
> Ah, yes, you're right. It's shared-mime-info (the database) which is GPL.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120528/84655290/attachment.html>