Fortunately, the Nepomuk developers have come up with a high level API to query already stored metadata, and today’s post will deal with querying tags in Nepomuk. As per the past tutorials, the full source code is available in the kdeexamples module.

Let’s start off with the basic imports:

import sys

import PyQt4.QtCore as QtCore

import PyKDE4.kdecore as kdecore
import PyKDE4.kdeui as kdeui
from PyKDE4.kio import KIO
from PyKDE4.nepomuk import Nepomuk
from PyKDE4.soprano import Soprano

Then let’s create a simple class that wil be used for the rest of this exercise:

class NepomukTagQueryExample(QtCore.QObject):

    def __init__(self, parent=None):

        super(NepomukTagQueryExample, self).__init__(parent)

__init__ is just used to construct the instance, nothing more. The bulk of the work is in the query_tag() function, which we’ll take a look at in parts.

    def query_tag(self, tag):

        """Query for a specific tag."""

        tag = Nepomuk.Tag(tag)

First of all we convert the tag we want to query into a proper Nepomuk.Tag() instance. Of course we should use an already existing tag: even if Nepomuk.Tag() automatically creates new tags, it makes little sense to query for a newly created tag, doesn’t it?

For our job, we need to use properties which define the terms of our query. As we’re looking for tags, we’ll use Soprano.Vocabulary.NAO.hasTag():

        soprano_term_uri = Soprano.Vocabulary.NAO.hasTag()
        nepomuk_property = Nepomuk.Types.Property(soprano_term_uri)

The first call generates an URI pointing to a specific RDF resource for this specific term, which is then wrapped as a Nepomuk.Types.Property in the second call. While the C++ API docs don’t show this, I found it to be necessary, or the Python interpreter would raise a TypeError. Notice that this is not the only term we can use: aside for tags, there are a lot of other URIs we can use for querying, listed in the Soprano API docs.

Once we have our property set up, it’s time to define which kind of query we’re going to use. In this case, since we want to check for the presence of tags, we use a Nepomuk.Query.ComparisonTerm, which is a query term used to match values of specific properties (in our case, tags):

        comparison_term = Nepomuk.Query.ComparisonTerm(nepomuk_property,
                Nepomuk.Query.ResourceTerm(tag))

Our tag is wrapped in a ResourceTerm, which is used exactly for the purpose. Now we make the proper query: in this specific case, we want to look up files tagged, so we use a FileQuery. We could also get other items, such as mails (in Akonadi): in that case we could use a a Nepomuk.Query.Query():

        query = Nepomuk.Query.FileQuery(comparison_term)

Lastly, we want to get some results out of this query. There are different methods, but for this tutorial we’ll use the tried-and-tested KIO technology:

        search_url = query.toSearchUrl()
        search_job = KIO.listDir(kdecore.KUrl(search_url))
        search_job.entries.connect(self.search_slot)
        search_job.result.connect(search_job.entries.disconnect)

First we convert the query to a nepomuksearch:// url, which then we pass to KIO.listDir, to list the entries. Unlike my previous post on KIO, this job emits entries() every time one is found, so we connect the signal to our search_slot method. We also connect the job’s result() signal in a way that it will disconnect the job once it’s over.

Finally, let’s take a look at the search_slot function:

    def search_slot(self, job, data):

        # We may get invalid entries, so skip those
        if not data:
            return

        for item in data:
            print item.stringValue(KIO.UDSEntry.UDS_DISPLAY_NAME)

Entries are emitted as UDSEntries: to get something at least understandable, we turn them into the file name, which is obtained by the stringValue() call using KIO.UDSEntry.UDS_DISPLAY_NAME.

That’s it. As you can see, it was pretty easy. Of course there’s more than that. For further reading, take a look at Nepomuk’s Query API docs, and Query Examples. Bear in mind however that to the best of my knowledge, the “fancy operators” mentioned there will not work with Python.

Happy Nepomuk querying!

How do I get it?

git clone http://git.gitorious.org/kde-vlc-snapper/kde-vlc-snapper.git

sudo python setup.py install

kdevlcsnapper

With the adoption of Review Board to facilitate code reviews, there were also requests for a REVIEW keyword that could close the review requests without asking the submitters to do so manually (which is slow and not always effective). Since the hooks for Git were written in Python, I thought I could give a hand there.

I looked into the Review Board API, which is a simple REST API: tasks are performed with HTTP GET, POST, or PUT. As I didn’t want to dive too much into the technicalities, I decided to use a wrapper that would make things easier: python-rest-client. Once that was in place, it was just a matter of adding some sugar to handle replies, errors and logging. All in 78 lines of code.

Now that the “field tests” passed with flying colors, I’m happy to announce that such a hook exists and is operational for KDE’s Git infrastructure. By using the REVIEW keyword at the start of a line, followed by a number, the hook will notify the Review Board instance and close the request. It will also publish a comment stating the commit’s SHA1 and the person who did it.

You can take a look at the finished results in this review request.

Credits for this also go to Ben “bcooksley” Cooksley for helping with testing and fixes, and Eike “Sho” Hein for helpful suggestions.

Bear in mind that everything for now is running on a testing server, to make sure it doesn’t break anything. Once the tests and the implementation are complete, we’ll integrate the feature in the forums. How soon we are not sure, but it won’t be too long.

"Help me post a topic"

Upon logging in, you will be greeted by a new "New Post" button:

You can either click on the arrow to quickly post an idea for Brainstorm, a new discussion, access the "getting started" forum or contact the staff:

Or if you just click on the button itself, you access the guided post section:

The "Share an idea" and "Chat and discuss" buttosn will bring you to the relevant forums (Brainstorm and Discussions and Opinions), while "Ask a question" will bring about an additional screen:

You’ll be able to select your favorite application and you’ll be able to post directly in the relevant forum.

Open Collaboration Services

But that’s not all. Thanks to the hard work of Ben Cooksley (fellow admin and System Settings maintainer) there is also an implementation of the Open Collaboration Services (OCS), the same system that powers the well-known Get Hot New Stuff connected to OpenDesktop.org. This will mean, in principle, that you could access forum posts and discussions in a programmatic way, using a REST API. This opens up possibilities like Brainstorm plasmoids, other means to access the forum (like an Akonadi resource – there’s some ongoing work in KDE SVN). If you’re interested in testing the OCS for the forum (or if you want to develop some kind of application that ties to the forums themselves), let us know on IRC (#kde-forum on freenode).

I knew already that the various ioslaves can store metadata, consisting of key-value pairs which are specific on the slave used. Normally you can get the whole map by accessing the metaData function of the job you have used, in the slot connected from the result signal. For some reason, however, in PyKDE4 calling metaData() triggers an assert in SIP, which ends in a crash (at least in my application; I stil need to debug further). KIO jobs have also the queryMetaData function, which returns the value of the key you have queried. Unfortunately, there was no way I could find the name.

Thus began my search for the right key. Googling didn’t help, and on IRC I got the first answers I needed but not enough to reach the goal. Until I saw a commit by David Faure in trunk/kdelibs/kio/ which touched a file called DESIGN.metadata (link is for the branch version). After checking with webSVN, that was exactly the thing I was looking for! It lists all the keys for the metadata, indicating also to which ioslave they begin. After that, the solution was easy.

Of course I’m not leaving you hanging there and now I’ll show you how, in PyKDE4, you can quickly check for the server response:

from PyKDE4.kio import KIO
from PyQt4.QtCore import SIGNAL
[...]

class my_widget(QWidget):
[...]

    def check_address(self, url):

        # You can add optional flags such as KIO.HideProgressInfo
        job = KIO.get(KUrl(url))
        self.connect(job, SIGNAL("result (KJob *)"), self.slot_result)

    def slot_result(self, job):

        if job.error():
            # Bail out if there's an error
            return    

        # Get the HTTP response through queryMetaData
        http_response = job.queryMetaData("responsecode")
        print "Got response: %s" % unicode(http_response)

This snippet does a few things. Firstly, it gets the specified URL, using KIO.get (KIO.stat doesn’t set the required metadata). Notice that the call is not wrapped in the new-style PyQt API because result (KJob *) isn’t wrapped like that (there’s a bug open for that). In any case, the signal passes to the connecting slot (slot_result) where we first check if there’s an error (perhaps the address didn’t exist?) and then we use queryMetaData("responsecode") to get the actual response code.

If you want to do error checking basing on the result, bear in mind that KIO operates asynchronously, so you should use a signal to tell your application that the result is what it expected or not.

I wonder if this should be documented in Techbase…

Well, it took me more than a month to get this thing done… I didn’t spend every day coding, but it was a challenge. Glad it’s over now, which means that Danbooru Client 0.5 is finally available. Grab it at the usual place on kde-apps.org.

Changes in this version:

• Massive code refactoring and documentation
• Support for multiple pages: the same query can be repeated multiple pages (shown in a tabbed interface), kind of like browsing the actual Danbooru board;
• Rating information added to the API;
• Support for translations (thanks to Pino "pinotree" Toscano for the help): the tarball now contains a .pot file which can be used for translating Danbooru Client. If you make a translation, send the .po file my way and I’ll include it in the next version.

Improvements that I have in the queue:

• Suppport for pools (every board out there changes the API, so it will require some work);
• Support for storing password/username using KWallet (through python-keyring, so it works even without KWallet installed);
• Review usability of the dialogs (I have a separate branch for that);
• Improve the image download dialog.

On recent KDE SC versions (4.4 beta 2 and onwards) there are some painting issues with regards to the thumbnails, but I’m not sure if the fault is in PyKDE4 or in the underlying libraries. Nothing too bad, luckily: hovering the thumbnails or giving focus to the thumbnail view should be what’s needed.

Here’s a screenshot of the new interface (click to enlarge):

Comments and suggestions are always welcome, so don’t hesitate to drop me a line.

As a final word, some thoughts on the work required to get this out of the door. My largest issues are related to garbage collection: Python’s reference counting based GC got a lot in the way, at least because of how the underlying C++ structures work. I had to work a bit to keep references to objects around so I wouldn’t get crashes (accessing an already deleted object). All is well now, and I think my Python/PyQt/PyKDE4 knowledge gained from it. I keep telling myself that I should be writing some tutorials one day…

Today, the KDE Community Forums would like to provide the opportunity to answer those questions by annoucing the continuation of the tutorial courses known as Klassrooms.

What are Klassrooms?

Klassrooms are tutorial “lessons” held in a specific area of the forum. Held by one or more “mentors”, they are focused in guiding people through helping KDE by tackling a particular problem. Examples of such problems include:

• Fixing simple bugs in an application
• Taking junior jobs in a specific project
• Helping with documentation
• Promotion work (for example, screencasts)
• Helping with translations

As you can see, Klassrooms are not limited to coding at all.

Usually the sessions last from one to two weeks, with a maximum of 5 “students” participating. The work is coordinated in a specific area of the forum.

Public call for mentors

The key to hold Klassrooms is having mentors. Their role is to present the problem and guide students through the course. Compared to a live session, using the forum requires less time, and both the students and the mentor can set their most convenient schedule.

That is why we need you! You don’t need to be a developer: non-coding courses are as welcome as coding ones. How do you become a mentor? These guidelines explain everything that is needed to apply.

If you feel like helping, this is the perfect opportunity. Let us know!

The first encounter worked out pretty well, actually. I went with the others to have a dinner out, and I got to talk to “famous” KDE people such as Troy, Lydia, or Jos. I also had the nice opportunity to meet up with my fellow forum administrator neverendingo, and we discussed a bit on how to improve the forums. In short, the evening was really nice. I even got to see a N900! I thought I’d never see that. A very nice piece of hardware, I’d say.

The following morning, aside a little incident (the other people forgot about me!) I walked up to KONSEC where the meeting was held. While Cornelius led the discussion (the Dot will have more details in due time), I worked on helping out with a promo booklet the team is making. I’m used to writing, but writing in an appealing way to a less specialized audience is much harder. Thanks go to Jos who got me on the right track.

Then part of the people moved to another room to discuss about getting new contributors to KDE while I stayed with Jos and Stuart to work on other material. It was a little draining, but very productive overall. I am actually happy to be part of this, for a change, rather than passively reading about it on the web. It’s nice to give something back to your favorite project, as little as may be.

Lastly, we went out for a dinner in an Indian restaurant (nice food, not too much though), and we went back (with Eckhart showing us innovative ways to get back by changing multiple subway trains). And here I am, writing a small report of this day.

It’s been a very positive experience so far. I finally saw more people who use KDE, and they’re also both fun and nice. Now it’s time for bed, I still have a good half of a day for work before I get back.

Once you save the file, however, all the tags are just present in your file name, and nowhere else. LIke that, they’re not that informative. That’s where danbooru2nepomuk comes into play. danbooru2nepomuk is a small Python program that can turn the tags present into the filenames into real semantic tags.

Requirements

As of this post, danbooru2nepomuk works only on Linux, so if you are a Windows user, you’re out of luck. Also, it requires a KDE (tested with version 4.3.1).

danbooru2nepomuk is a Python program, so it requires first of all the Python interpreter, version 2.5 or later. It has been developed to use the Nepomuk semantic desktop framework present in KDE, so you’ll also need PyQt4 and PyKDE4, along with a working Nepomuk installation. Most distributions use the broken Soprano redland backend, which will not work, so I suggest you to switch to the sesame2 backend, which (although dependent on Java) works reasonably well.

Download and installation

Simply get danbooru2nepomuk.zip, rename it to .py from .zip, save it in your PATH, and make it executable. Nothing more than that.

Usage

danbooru2nepomuk is a command line appplication. Its syntax is simple:

danbooru2nepomuk.py [-r] <file or directory>

If you specify a file, it will be tagged directly; if you specify a directory, it will be scanned for files, and those in turn will be tagged. If you add the -r switch to a directory, it will be scanned recursively, while it will be simply ignored if you use it with a file.

Configuration

You can specify a tag blacklist for tags in the filename that you don’t want to get in. To do so, edit the TAGS_BLACKLIST variable on line 41, and add more tags you don’t want Nepomuk to pick up.

Known issues

None that I know of, at least! If you find any, let me know.

danbooru2nepomuk is licensed under the GNU General Public License, version 2.