PyKDE4: Tag and annotate files using Nepomuk

Some time has passed since I last blogged… this was not only due to lack of time but also due to motivation (writing long texts can be discouraging at times). In any case, I’d like to rectify for that. In this post, I’ll talk about Nepomuk, and in particular how to use it to tag and annotate arbitrary files using its API in PyKDE4.

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.

OCS and KDE Forums – work continues

With my last entry, I announced the start of the work for an OCS library for the KDE Community Forums. Today I’d like to blog again about the recent developments.

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!

Open Collaboration Services and KDE Forums

For KDE developers, web-based forums are often uncommon workflows. Indeed, for communication among developers mailing lists are much better tools, especially since you can handle everything inside a client (most of the time), compared to forums where you have to use a web browser. The ways of reading, replying and interacting with posters are dramatically different. And that is why some developers find themselves uncomfortable with the KDE Community Forums.

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.