exdgmime

[DAV]

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 <dav.daemon at gmail.com> написал:

> > 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 <faure at kde.org> написал:
>
> 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, 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/20120228/0138bb05/attachment.html>