exdgmime

[DAV]

> 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/20120222/d7f76c14/attachment.htm>