We are not sure how our users would react if we remove the X screen savers and replace them by a new solution. We would like you to contribute and share your opinion. Tell us why you need screen savers and how you would think about if the currently used screen saver could no longer be used.

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.

Before starting, let me say that creating this tutorial was only possible thanks to the help of Sebastian Trueg, who helped me by pointing out some mistakes I was doing.

The example here is not showing the extra methods to set up a KApplication, etc.: the full code for this tutorial is available in the kdeexamples module.

Let’s start with the basics.

import sys
from PyQt4 import QtCore
from PyKDE4 import kdecore
from PyKDE4 import kdeui
from PyKDE4.nepomuk import Nepomuk

This will import all the bits needed to test our experiment. As a second step, we’ll create a dummy empty file.

dummy_file = open("dummy.txt", "w")
dummy_file.write("Some text\n")
dummy_file.close()

Or, if we have Python 2.6+ (as pointed out in the comments):

with open("dummy.txt", "w") as handle:
    handle.write("Some text\n")

Now that we have our file, it’s time to do something productive with it. But first and foremost, we have to ensure that Nepomuk is running. To do so, we make a simple check (EDIT: fixed the syntax):

result = Nepomuk.ResourceManager.instance().init()
if result != 0:
     return

Neomuk.instance().init() must return 0 if Nepomuk is properly set up. Once this is taken care of, we can manipulate the semantic information of our file. Thus, Nepomuk needs to be made aware of it: this is done by creating a resource that points to the actual file:

file_info = QtCore.QFileInfo("dummy.txt")
absolute_path = file_info.absoluteFilePath()
resource = Nepomuk.Resource(kdecore.KUrl(absolute_path)

Notice that we must use an absolute file path, or the resource will be not created properly and although no errors will happen when tagging, changes will not be made. Let’s now create a tag, which is done by simply constructing a Nepomuk.Tag instance:

tag = Nepomuk.Tag("test_example")
tag.setLabel("test_example")

In the first line we create the tag, then we associate it with a label, so that it will be displayed in applications such as Dolphin. The nice thing is that if the Tag already exists, it will be recycled: no duplicates will occur. A simple call to addTag to the resource we created earlier will now tag it:

resource.addTag(tag)

We can also add comments that can show up in Dolphin as well by using the setDescription method:

resource.setDescription("This is an example comment.")

What if we want to remove tags and descriptions? To wipe them all, we can use the remove() method of the Resource, otherwise we can strip elements by using removeProperty along with the tagUri() or descriptionUri() methods of the resource:

resource.remove() # strip everything
resource.removeProperty(resource.descriptionUri()) # remove comment
resource.removeProperty(resource.tagUri()) # remove tags

That’s it. As you can see, adding semantic information from PyKDE4 isn’t that hard. Sooner or later I’ll try my hand at queries and report back my findings.

The rest is up to you to figure out.

First of all, now there isn’t one, but two Python modules:

• ocslib, a pure Python module that can be used to interface with OCS-based forum systems;
• ocslibkde, a PyKDE4 based module that can be used to interface with OCS-based forum system in KDE applications.

Currently ocslib supports reading and posting, while ocslibkde only reading (as of now). Both can be retrieved from the kde-forum-mods repository under the ocs-client subdirectory. The Python lib needs unit-testing, then I’ll be able to push a tarball soon for people to test (but you can always check out the Git repository). With regards to the PyKDE4 library, I plan on making a proof-of-concept plasmoid soon that shows how to use the API.

Speaking of API, here are some examples using ocslib:

>>> from ocslib import service# Connect to OCS
>>> ocs_service = ocslib.service.OCService("http://www.example.com")
#Retrieve all forums
>>> forums = ocs_service.list_forums()
# Elements have attributes for name, posts, etc.
>>> print forums[0].name
"Test forum"
#Retrieve threads for forum 15
>>> threads = ocs_service.list_forum_threads(forum_id=15)
# Retrieve thread 8945 from forum 15
>>> messages = ocs_service.show_thread(forum_id=15, topic_id=8945)
>>> print messages[0].text
"Hello world!
#Post to a forum - requires authentication
>>> ocs_service = service.OCService("http://www.example.com", username="foo", password="bar")
>>> message = "Hello, KDE people!"
>>> subject = "Test message"
>>> ocs_service.post(forum_id=15, subject=subject, message=message)
True # Return code of operation

Feedback (especially on the API) welcome!

A dedicated application would be usually much better than a browser, because you can work around the intrinsic limitations of the browser itself. The problem is that you can’t really access a forum with anything else than a browser. That is, it used to be like this, but now things are changing.

In the past months fellow administrator bcooksley has been working quite hard implementing the Open Collaboration Services (OCS) specification in the KDE Community Forums. For the uninformed, it’s the same API that powers OpenDesktop.org and related web pages. This means that you could access the forum contents programmatically using a REST API and parsing the XML that is returned by the service.

Unfortunately, bcooksley had no time to implement a client that would make use of this newly-made service.

That’s where I stepped in. This morning I committed in the kde-forum-mods repository the first implementation of a backend to access the forums’ OCS service. Currently it’s extremely basic – just a few classes to wrap the XML responses into decent data representation, and a basic class to perform reading requests: that means that technically it is possible to request forum listings, thread listing, and posts. I’m still working on the ability of replying and posting messages.

Being a Pythonista, the backend is written entirely in Python: currently it uses the standard library plus dateutil and lxml to do its bidding, but the next steps would be to turn it into a PyKDE4 library to access all the KDE related goodness (hello, KIO!). Bear in mind that currently there is no application using this: I merely completed (part of) the backend.

If you’re interested, the code can be found on gitorious.org, in the ocs-client directory, branch experimental, inside the kde-forum-mods repository.