KDE Commit-Digest
I already have plans for 1.1 and big plans for 2.0 which will be the first KDE 4 release of K3b. For K3b 1.1, I plan to merge CD and DVD projects with the introduction of Blu-ray support. Having yet another project type is just confusing. Thus, I will not make a distinction between CD, DVD, or Blu-ray anymore. There will only be one copy dialog and only one data project. For K3b 2.0 I plan a big refactoring of libk3b which will result in a very modular API consisting of image creators and image writers. An image creator will then be connected to a writer in a generic manner. Also, K3b 2.0 will introduce the K3b image format which means that images created via K3b will contain all the necessary information to write them back to media later on.
Besides K3b, I have big hopes for NEPOMUK-KDE or, better, KMetaData. I just moved it to the kdereview module to give people the possibility to have a look at it and test it. I think there is still big confusion about what it is good for.
So far, KMetaData provides a nice API for creating metadata for all kinds of information, for example files. The SVN version of Dolphin already contains file rating, tagging, and commenting features using KMetaData. The code to achieve this is quite simple.
I present this example often but I think it is worth mentioning it again:
// create a new File instance
KMetaData::File f( "/tmp/trueg/testfile" );
// make sure the path (called location here) is set properly
f.setLocation( "/tmp/trueg/testfile" );
// now set some metadata
f.setRating( 5 );
f.setComment( "I am a comment" );
Looks very simple and it is. The nice thing is that the File class has been auto-generated from an ontology. The ontology defines which resource types have which properties. They also contain information like localised labels and comments for properties. The latter could be used to create a metadata GUI in a generic manner. An API for this (the localised labels) does not exist yet but is planned. The idea is to categorize metadata via these ontologies.
To give you a bigger example of what KMetaData is intended for: I recently talked to Christian Muehlhaeuser from Amarok and he was very interested in the replacement of the Amarok collection with the KMetaData store. The benefits would be:
- Strigi would take care of gathering all the metadata from the files like the artist or the title.
- Amarok would have access to this information without "building the collection".
- The rating and the tagging in Amarok would be reusable in all other applications, for example desktop search.
- Within Amarok more advanced information could be stored and in the future nice features could emerge:
- Amarok could not only use the last.fm hints for recommendations, but also stuff like "which other tracks were often in the same playlist as the current one".
For this to be doable we need to extend the KMetaData API with nice query functionalities. ATM it is possible to perform full SPARQL queries on the RDF repository which we store the metadata in but it would be nice to have a simpler API for the day-to-day work.
I would really appreciate input on this.
- Amarok could not only use the last.fm hints for recommendations, but also stuff like "which other tracks were often in the same playlist as the current one".
