<div style>Hi, all!<br><br>I finally did it :) I have update libxdg documentation:<br> - here is the small Wiki with basic info about the library: <a href="https://github.com/vilkov/libxdg/wiki" target="_blank">https://github.com/vilkov/libxdg/wiki</a><br> - here is updated online Doxygen documentation: <a href="http://vilkov.github.com/libxdg" target="_blank">http://vilkov.github.com/libxdg</a><br> - and code itself: <a href="https://github.com/vilkov/libxdg" target="_blank">https://github.com/vilkov/libxdg</a></div> <div style><br></div><div style>Could you possibly take a look at the documentation please, especially if you are Stake Holder, like e.g. David :)</div> <div style>If there won't be suggestions, I will create a release tag (0.2) at 19:00:00 Monday May 28, 2012 in GMT.</div><div style><br></div><div style> <span>> > * List of XdgFileWatcher structures</span><br><span>> </span><br><span>> </span><span>Can you explain what these are for? Each path, in that list, is that a cache</span><br> <span>> </span><span>file or a desktop file, or a directory of desktop files?</span><br><span>> </span><br><span>> </span><span>But more generally, could we get rid of the whole idea of file watching, and</span><br> <span>> </span><span>just mandate that when someone installs a .desktop file, they must run update-</span><br><span>> </span><span>applications-cache, just like we do with mimetypes and update-mime-database?</span></div> <div style>It's just like you said - there is no any file watching facility. This structures is used just</div><div style>for checking validity of cache files.</div> <div style><div><span style="color:rgb(51,51,51);font-family:inherit;font-style:inherit;line-height:12px"><br></span></div><div><span>> </span><span>Ah, heh, took me a long time to understand this. OK, this is the full contents</span><br> <span>> </span><span>of the desktop file itself, as a tree. Maybe simply add a typical example here.</span><br></div><div><span style="color:rgb(51,51,51);font-family:inherit;font-style:inherit;line-height:12px">I will, but in the next release (after 0.2), because I'm in release rush now (at my job).</span></div> <div><span style="color:rgb(51,51,51);font-family:inherit;font-style:inherit;line-height:12px"><br></span></div><div><span>> </span><span>"text" is not the name of a mime type. "text/html" is. Is there any reason for</span><br> <span>> </span><span>splitting text/html into two leaves in the tree? Is this for supporting</span><br><span>> </span><span>mimetypes like text/* or image/*? Hmm, why not. But otherwise it's a bit</span><br> <span>> </span><span>pointless and confusing.</span><br></div><div><font face="arial, sans-serif"><div style="color:rgb(34,34,34)">Hmm... It could be so, but the reason of this is performance. When we have</div><div style="color:rgb(34,34,34)"> only tens of mime types it won't be a problem, but when we are speaking about</div><div style="color:rgb(34,34,34)">thousands or even tens of thousands for each mime group/sub type</div><div style="color:rgb(34,34,34)"> <span> </span>(i.e. application/ text/ etc) it will be a serious problem.</div> <div style="color:rgb(34,34,34)"><span> </span></div><div style="color:rgb(34,34,34)"><span>> </span><span>> Each value of this tree is an AVL tree of sub types (e.g. html), which</span><br><span>> </span><span>> contains a list of pointers to XdgApp structures.</span><br> <span>> </span><br><span>> </span><span>What does this structure contain? The full contents of the desktop file, again?</span><br><span>> </span><span>Or do I misunderstand that?</span><br> <span>> </span><span>Surely there's no need to duplicate the contents again, for each mimetype</span><br><span>> </span><span>associated with the application. Wouldn't it be enough to write in this tree,</span><br> <span>> </span><span>the name of the desktop file, in order to then look it up in the other tree if</span><br><span>> </span><span>one wants to get more details about it?</span><br> <span>> </span><span>Or is this space-optimized anyway, by pointing to the same data in the on-disk</span><br><span>> </span><span>cache?</span><br><span>> </span><span>Please tell me more about what this tree contains, the documentation is</span><br> <span>> </span><span>confusing, my talking about structures here, but not in the first tree, but</span><br><span>> </span><span>they seem quite similar.</span><br><span>> </span><br> <span>> </span><span>> Note: Global version of this tree is used to resolve ".desktop" files</span><br><span>> </span><span>> according to the given mime type.</span><br> <span>> </span><br><span>> </span><span>?? What's Global version? The one in /usr? Why is it special? Surely desktop</span><br><span>> </span><span>files in $XDG_DATA_HOME can mention mimetypes too.</span><br> <span>> </span><span>I'm not sure what you call resolving, here, in any case.</span><br><span>> </span><br><span>> > AVL tree of all ".list" files located in the same directory as cache file.</span><br> </div><div style="color:rgb(34,34,34)"><div>Well as I mentioned before old documentation was a bit outdated and, lets say,</div><div>didn't describe whole things clearly enough... I hope new one will.</div></div><div style="color:rgb(34,34,34)"> <br></div><div style="color:rgb(34,34,34)"><span>> The typical use case for all this, is "what are the apps associated with a</span><br> <span>> </span><span>given mimetype, sorted by user preference", right?</span></div><div style="color:rgb(34,34,34)">Yes, it is.</div><div style="color:rgb(34,34,34)"><br><span>> </span><span>With a tree for the associations coming from desktop files, and another tree</span><br> <span>> </span><span>for the contents of defaults.list/mimeapps.list, one has to look up into</span><br><span>> </span><span>multiple trees to be able to answer that question. Wouldn't it be faster, and</span><br> <span>> </span><span>simpler (higher level) to have a single tree, combining these two?</span><br><span>> </span><span>I.e. a simple tree with</span><br><span>> </span><span> key = mimetype -> value = list of desktop files</span><br> <span>> </span><span>("merging" .list files into the desktop files) would give an immediate result,</span><br><span>> </span><span>compared to three lookups (initial list, then added associations, then removed</span><br> <span>> </span><span>associations), all this multiplied by the number of paths in XDG_DATA_DIRS</span><br><span>> </span><span>plus one local dir, of course.</span></div></font><div>Everything just the way you describe it - <span style="color:rgb(34,34,34);font-family:arial,sans-serif">the library returns merged results from</span></div> <div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">all </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">XDG_DATA_DIRS </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">directories and local directory too</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">. When one </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">asks the library</span></div> <div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">about, e.g. default </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">associations the library returns a list of apps from all ".list" files</span></div> <div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">(system-wide) </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">there is no initial list and there is no need (and actually possibility too)</span></div> <div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">to scan </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">XDG_DATA_DIRS. All this implementation details (like XDG_DATA_DIRS and</span><font face="arial, sans-serif"><div style="color:rgb(34,34,34)"> local dir) encapsulated in the library.</div><div style="color:rgb(34,34,34)"><br></div><span style="color:rgb(34,34,34)"><div>> Do you think this could be done? Or am I overlooking some difficulty here?</div><div>It could easily be done by adding one more function which will group the results from</div> <div>different groups ("Default Associations", "Added associations", etc).</div><div>By the way, this functionality is implemented in example in online documentation.</div><div><br></div></span></font></div> <font face="arial, sans-serif"><div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);font-family:inherit;font-style:inherit;line-height:12px">------------------------------</span><span style="color:rgb(51,51,51);font-family:inherit;font-style:inherit;line-height:12px">--</span></div> </font></div> </div><div style="line-height:12px;font-family:Arial,Helvetica,'Nimbus Sans L',sans-serif"><h3 style="font-family:inherit;font-style:inherit;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:initial;outline-width:0px;outline-style:initial;outline-color:initial;font-weight:inherit;vertical-align:baseline;color:rgb(51,51,51)"> <font>Best regards, Dmitriy.</font></h3></div><br> <br><br><div class="gmail_quote">2012/5/23 David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div>On Wednesday 23 May 2012 10:03:33 Sanel Zukan wrote:<br> > > This starts with "This library is a fork of the official <a href="http://freedesktop.org" target="_blank">freedesktop.org</a><br> > > library xdgmime". This is not the case anymore, is it? In fact, is there<br> > > any code from xdgmime? I hope not, since it's GPL, and your code is LGPL.<br> ><br> > Hm... isn't xdgmime under LGPL?<br> <br> </div></div>Ah, yes, you're right. It's shared-mime-info (the database) which is GPL.<br> <div><div><br> --<br> David Faure, <a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5<br> <br> </div></div></blockquote></div><br>