Hi, all! Third release candidate of libxdg is out. Here is the change list: - got rid of "int" in cache (replaced by "xdg_uint32_t"); - added possibility to build the cache for a given directory; - binary "update-applications-cache" updated according to the previous point; - added function "xdg_app_refresh()" for updating loaded data (after initialization of the library); - few bug fixes were made; - documentation updated;
-------------------------------- Best regards, Dmitriy. 22 февраля 2012 г. 14:54 пользователь DAV <[email protected]> написал: > > I thought the previous discussions led to the conclusion of rather > making this > > a separate library from xdgmime? I.e. calling it xdgappcache or > something, and > > removing all the xdg-mime stuff from it? > > I don't mind either way personnally, though. > > Yes, you are right. I was working on such feature at the moment of my > previous > letter. But now it's done. Also I have renamed the library to xdg > (libxdg), because > I think this name better reflects the functional of the library. > > So, here is the changes ("https://github.com/ZeR0God/libxdg";, tag > "rc-0.1.2"): > - first of all, now CMake project contains 3 targets (xdg, doc and > update-applications-cache); > - CMake flag: BUILD_MIME_SPEC (Build library with "Shared MIME-info > Database"); > - CMake flag: BUILD_DESKTOP_SPEC (Build library with "Desktop Entry > Specification"); > - CMake flag: BUILD_THEMES_SPEC (Build library with "Icon Theme > Specification"); > - CMake flag: BUILD_UPDATE_APPLICATIONS_CACHE (Build executable for > rebuilding the cache). Note: there won't be target > "update-applications-cache" if this > flag is set to false; > - I've created "FindXDG.cmake" script (it will help to find the library > with native > CMake tools, i.e. "find_package"); > - target "install" is working properly. > > You can choose flags to get the library with exact functional you need. > > > I checked out the code, but for easier thinking, do you have a > documentation > > of the binary cache data format? This is important for the future anyway > > because, just like with mime.cache, there will be other implementations > > reading directly from the cache (rather than linking to libxdgappcache). > > I will document this format when I will be documenting internal parts of > the library. > I think it will be third or fourth release candidate. > > > One thing I noticed: all the data types in the binary cache should have > fixed > > size. Using "int" or "long" is just recipe for trouble in the long run > > (portability issues). > > Thanks, I will fix it in the next release candidate. > > > The executable is all I need personnally. But shouldn't there also be a > > library (for reading the cache), and unit tests using that library? > > > > This is the best way to ensure that the implementation is correct: a > binary > > for writing the cache, a library and a unit test for reading from it and > > checking that it's all as expected. > > > > For parallel with the mime stuff: update-mime-database in > shared-mime-info is > > the first one, xdgmime is the library and the auto tests in > shared-mime-info > > use xdgmime to validate that everything works. > > > > If "xdgappscache" is made a separate package, it could provide all three, > > IMHO. > > Yes, it is. As I mentioned above, now CMake project contains target "xdg". > Unit tests will be added a little bit later. > > > That's cool - they are in the cache too? > > Yes, cache contains all data from ".desktop" and ".list" files (and all > this > stuff is indexed by using of AVL trees which means the fastest possible > access to this data). > > > Missing feature: taking a path on the command line, to generate the > cache for > > that path (rather than for /usr/share/applications). Again, much like > update- > > mime-info :-) > > :) Yep, you're right again. I'm planning to do so for the next release > candidate. > > > This is necessary in order to allow local desktop files too (e.g. > > ~/.local/share/applications). And the lib has to read from all xdg data > dirs > > of course. > > Yes, lib does and I will fix the cache for the next release candidate. > > -------------------------------- > Best regards, Dmitriy. > > > 19 февраля 2012 г. 14:39 пользователь David Faure <[email protected]> написал: > > On Friday 17 February 2012 13:38:34 DAV wrote: >> > Hi all, >> > I'm glad to announce the first release candidate of "exdgmime" library. >> >> I thought the previous discussions led to the conclusion of rather making >> this >> a separate library from xdgmime? I.e. calling it xdgappcache or >> something, and >> removing all the xdg-mime stuff from it? >> I don't mind either way personnally, though. >> >> > So, here is the changes: >> > >> > - serialization/deserialization of content of ".desktop" and >> > ".list" files (with indexes) into a binary cache file which can be >> mmap'ed >> > without need to rescan whole system directories. Reading of this cache >> > file is done without a single allocation of memory (just update pointers >> > in mmap'ed memory); >> >> I checked out the code, but for easier thinking, do you have a >> documentation >> of the binary cache data format? This is important for the future anyway >> because, just like with mime.cache, there will be other implementations >> reading directly from the cache (rather than linking to libxdgappcache). >> >> One thing I noticed: all the data types in the binary cache should have >> fixed >> size. Using "int" or "long" is just recipe for trouble in the long run >> (portability issues). >> >> int read_version(void **memory) >> { >> int version = (*(int *)(*memory)); >> >> (*memory) += sizeof(int); >> >> return version; >> } >> >> The mime.cache format is all made from "card16", "card32" and strings. >> >> > - a cmake project configuration file which contains two targets: >> > "update-applications-cache" (it is executable which rebuilds the cache) >> and >> > "doc" (generates Doxygen documentation); >> >> The executable is all I need personnally. But shouldn't there also be a >> library (for reading the cache), and unit tests using that library? >> >> This is the best way to ensure that the implementation is correct: a >> binary >> for writing the cache, a library and a unit test for reading from it and >> checking that it's all as expected. >> >> For parallel with the mime stuff: update-mime-database in >> shared-mime-info is >> the first one, xdgmime is the library and the auto tests in >> shared-mime-info >> use xdgmime to validate that everything works. >> >> If "xdgappscache" is made a separate package, it could provide all three, >> IMHO. >> >> > - a convinient access to localized values of entries of a ".desktop" >> files. >> >> That's cool - they are in the cache too? >> >> That's something I really miss in mime.cache, for easier deployment (I'd >> like >> to only deploy the cache, on systems without shared-mime-info installed). >> >> Thinking about it, it's less important with desktop files. We can just >> open the >> desktop file to read the translated comment, the point of the app cache is >> really the querying by mimetype... but OK if it's available, that >> certainly >> makes things faster. >> >> >> Missing feature: taking a path on the command line, to generate the cache >> for >> that path (rather than for /usr/share/applications). Again, much like >> update- >> mime-info :-) >> This is necessary in order to allow local desktop files too (e.g. >> ~/.local/share/applications). And the lib has to read from all xdg data >> dirs >> of course. >> >> -- >> David Faure, [email protected], http://www.davidfaure.fr >> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 >> >> >
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
