Home > Krita > Implementing Nepomuk as another backend for tagging

Implementing Nepomuk as another backend for tagging

Hi KDE Folks,

     I got some nice comments on tagging review in the previous week. The most important points in the review are

1). Required a unittest for the new tagging class

     For this one I created a test named KoResourceTagging_test in libs/widgets/tests and it does all the unit test required for the tagging class. I tested all the functionalities of tagging class by taking various examples. And the testing helped me to find out two logical bugs. I solved them also. 😀

2). Interaction wise needs some improvement.

    The tooltips of the icons under the tagging lineedit are improved, so that they don’t seem to belong to the tagging process. This is the one change I corrected but still need to get reviews from users. So, that I can improve it better.;)

3). Nepomuk as another backend

    Many KDE people are asking the question ” why don’t you use nepomuk as backend ? ” For this, the only answer we have is ” we need compatibility with GIMP tagging system.” But afterwards we felt that ” why don’t we implement nepomuk as another backend along with XML ?”. Then Boudewijn Rempt suggested to go on in this direction and we started working . .

The plan for implementing this change is that

Whenever application is running, we will use tagObject (QMultiHash Object) for all adding, deleting and searching irrespective of backend. But at the time of storing or retrieving,there will be some change.

Just we will provide some option to the user, asking whether he uses nepomuk or XML ?

  • If user wants Nepomuk, we will store tags info by Nepomuk by adding two more functions : readNepomukRepo() and writeNepomukRepo() in KoResourceTagging class
  • If users wants XML , we will have the functions readXML() and writeXML already. we will use them

But I face some problems in implementing this idea ,

This is the code :

void KoResourceTagging::writeNepomukRepo()

{

  qDebug() << ” I am in ;”;

  QStringList resourceNames = m_tagRepo.uniqueKeys();

  qDebug() << “Resource Names List : ” << resourceNames;

  foreach(QString resourceName, resourceNames) {

     qDebug() << ” Resource name : ” << resourceName ;

     KUrl kurl(resourceName);

     qDebug() << ” Kurl : ” << kurl.url();

      Nepomuk::File resourceFile = Nepomuk::Resource(kurl).toFile();

      qDebug() << “Resource File Created : ” << resourceFile.url().url();

      QStringList tagNameList = m_tagRepo.values(resourceName);

      qDebug() << ” Tag names : ” << tagNameList;

      foreach(QString tagName, tagNameList) {

            Nepomuk::Tag tag( “ResourceTag” );

            tag.setLabel(tagName);

            qDebug() << “Tag Created “;

            resourceFile.addTag( tag );

            qDebug() << “Resources tagged “;

      }

  }

}

And the output for this is

###

# This one is the output of brush resourceServer when it called writeNepomukRepo()

###

I am in ;

Resource Names List : (“/home/legend/krita-build/inst/share/apps/krita/brushes/A-eroded-cercle-anim.gih”, “/home/legend/krita-build/inst/share/apps/krita/brushes/A-wall-texture.gih”)

Resource name : “/home/legend/krita-build/inst/share/apps/krita/brushes/A-eroded-cercle-anim.gih”

Kurl : “file:///home/legend/krita-build/inst/share/apps/krita/brushes/A-eroded-cercle-anim.gih”

Resource File Created : “file:///home/legend/krita-build/inst/share/apps/krita/brushes/A-eroded-cercle-anim.gih”

Tag names : (“a”)

QObject::startTimer: QTimer can only be used with threads started with QThread

Tag Created

Resources tagged

Resource name : “/home/legend/krita-build/inst/share/apps/krita/brushes/A-wall-texture.gih”

Kurl : “file:///home/legend/krita-build/inst/share/apps/krita/brushes/A-wall-texture.gih”

Resource File Created : “file:///home/legend/krita-build/inst/share/apps/krita/brushes/A-wall-texture.gih”

Tag names : (“bricks”)

Tag Created

Resources tagged

###

# This one is the output of pattern resourceServer. It ends with this error.

###

I am in ;

Resource Names List : (“/home/legend/krita-build/inst/share/apps/krita/patterns/choc_swirl.pat”, “/home/legend/krita-build/inst/share/apps/krita/patterns/java.pat”, “/home/legend/krita-build/inst/share/apps/krita/patterns/wood4.pat”)

Resource name : “/home/legend/krita-build/inst/share/apps/krita/patterns/choc_swirl.pat”

Kurl : “file:///home/legend/krita-build/inst/share/apps/krita/patterns/choc_swirl.pat”

Fatal Error: Accessed global static ‘Nepomuk::ResourceManagerHelper *instanceHelper()’ after destruction. Defined at ../../nepomuk/core/resourcemanager.cpp:310

Aborted.

I need help to solve this problem ? 🙂

Categories: Krita
  1. Lukas
    July 3, 2011 at 10:09 pm

    >> Many KDE people are asking the question ” why don’t you use nepomuk as backend ? ” For this, the only answer we have is ” we need compatibility with GIMP tagging system.

    Can’t Nepomuk get exteded and have GIMP capable plugin? So it works like Krita Nepomuk XML GIMP.

    Same backend could be used in DigiCam, Gwenview, etc? 🙂

  2. July 3, 2011 at 10:30 pm

    Artists really shouldn’t need to be answering questions like “Should tags be stored in Nepomuk (huh? what’s that) or xml (huh? What’s that?)” Heck I even know what both of these are, but I still wouldn’t know the preferable answer to this…

    Is it possible to store the info in both and just not ask at all? Failing that, maybe it could be something that defaults to the Gimp compatible option and has an option in the settings to switch, with an explanation of the consequences and benefits.

    I think it’s reasonable to expect artists to understand the concept of tagging, but I don’t think it’s reasonable to expect artists to understand the difference between Nepomuk’s semantic resource database and XML’s approach to storing resource data.

  3. slangkamp
    July 4, 2011 at 2:20 am

    You can also use both at the same time. If the users has turned of Nepomuk it still works.

  4. TheBlackCat
    July 4, 2011 at 12:53 pm

    What about the GSOC project implementing tag writing for Nepomuk? If you talk to the person implementing that you might be able to get the tag writing you need implemented, or at least make it as easy as possible to add the capability later.

  5. cloose
    July 5, 2011 at 2:19 pm

    Have you already talked to the GSoC student with the project “Nepomuk Metadata Writeback” (http://who828.wordpress.com/2011/07/04/metadata-writeback-my-gsoc-project/)? It sounds like he is trying to solve the problem you have with using both Nepomuk and file specific metadata at the same time.

  6. July 6, 2011 at 4:37 pm

    @cloose
    That sounds reasonable. That would be more proper, but would not work when Nepomuk is turned off. If Krita devs want it to work without Nepomuk, the XML-writing would have to be used at two places: from Krita itself and from Nepomuk writeback.

  7. slangkamp
    July 28, 2011 at 2:15 am

    @cloose: It’s different from that. Gimp uses one xml file where all the tags are saved. Nepomuk Metadata Writeback would write the tags to each resouce file, which is not supported for these files.

  8. July 28, 2011 at 9:45 am

    So can both just be turned on all the time and just have it fail silently if one is not available (say Nepomuk doesn’t exist because it’s a Gnome desktop…)?

  9. August 2, 2011 at 11:33 pm

    If both are turned on at a time, then it will become a problem to choose the backend for loading tags at startup

  1. No trackbacks yet.

Leave a comment