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.

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).

My Akademy talk proposal was not accepted, but the organizers were kind enough to offer me the chance to hold a BoF on the same subject. Now I bet you wonder on what I’m going to discuss, and I think the title already gives you an idea:

KDE and bioinformatics: the missing link

Although in the KDE community we have our fair share of scientists (hey there, Stuart!), my BoF will focus on the adoption of KDE in the field of bioinformatics (my day job, not-so-by-chance) on the "outsiders" front and how to improve the current situation. To elaborate further, bioinformatics is a rather broad field where biological data are treated with computational methods. The oldest and most famous branch of bioinformatics is sequence analysis and related field, where sequences of DNA are analyzed, for example, to find common ancestors among several species, or to reconstruct the genetic code of an organism by comparing it to a related species. Another recent example is related to high-throughput technologies, technologies which produce huge amounts of data from a very small number of experiments ("ultramassive sequencing" and DNA microarrays are examples of such a technology).

Either way, bioinformaticians have to deal with large amounts of data all the time, and usually there’s no "shrink-wrap" solution to the problems they have to face, software-wise. That’s because we do research, so we need to find something new. So the solution is often to write algorithms, or re-implement existing ones in a form that is suited for the tasks at hand. So, bioinformaticians also write software, although they’re by no means (usually) professional coders: some have a mathematical or statistical background, others (like me) come from an experience at the lab bench. What kind of programs bioinformaticians write? Normally scripts and small stuff, but in certain cases even full blown-algorithms and applications. Some become so famous that are even trend-setters.

Which brings us to the heart of the matter: how does KDE stand in all of this? Sadly, not too well. I’ve done some research in the published literature, but there’s just one hit returned that’s proper: a KDE application for neuroscience (based on the 3.5.x Development Platform) published in 2008. I know that big research places like CERN use KDE, but to my knowledge smaller realities such as research group code in the majority of the cases for Windows or for web-based solutions. Given that at least a signficant portion of bioinformaticians uses UNIX-like operating systems, the question we need to answer is: why?

The first and foremost problem is related to market share. Research groups don’t even know that KDE exists, so it’s unlikely they develop something using the Development Platform (even now that’s becoming more cross-platform). This is where some promo efforts could help. Secondly, the problem lies in the "difficulty" (notice the quotes!) of developing using the KDE Development platform: most bioinformaticians, as I wrote, are not professional coders, and few of them know C++. The most used languages in bioinformatics are Perl and Java (with some Python and Ruby thrown into the mix). Thus, the need for proper bindings. The bindings are there, thanks to the excellent work of the kde-bindings team, but documentation is still lacking (namely in the examples department, but also in tutorials and getting started guides that aren’t aimed at C++). Some documentation is auto-generated, and while the KDE API docs are usually not too hard to read, they can still scare off newcomers. Of course this is not the fault of the kde-bindings team: namely, more help is needed.

Promo efforts and better bindings are the keys to spread KDE more in the field of the bioinformatics. This is what my BoF is about, plus an informal discussion on the use of FOSS in academia and related matters.

Interested? If you are, you can come to the BoF which will be on Tuesday, 6th July at 15.00 in the Area 2 of the main room at Demola.

I’ll also be around later till the following morning (sadly, two days is the best I can do to attend) in case you’re interested for a chat.

from PyQt4 import QtCore
from PyQt4 import QtGui
from PyKDE4 import kdeui

class MyGUI(QtGui.QWidget):

    def __init__(self, parent=None):
        super(MyGUI, self).__init__(parent)
        self.pushbutton = kdeui.KPushButton()
        self.pushbutton.setText("Push me!")

        QObject.connect(self.pushbutton, QtCore.SIGNAL("clicked()"),
                               self.button_pushed)

    def button_pushed(self):
        print "Button clicked"

The main advantage of this syntax is that it’s very close to the C++ equivalent, and so you can translate easily from C++ to Python. Unfortunately the advantages of this syntax end here. The disadvantages, at least from a Python coding perspective, outweigh the advantages:

• It’s extremely error-prone: make a typo, and not only your signal won’t be connected, but you won’t even get a warning, your program will simply do nothing;
• In case you have overloaded signals, you have to type the exact signature, going back to the first problem;
• It’s not Pythonic at all.

So, in recent PyQt versions (and thus also in PyKDE4) a new style approach was introduced (although the old style is always present should it be the need to). Using the new style, the signals become a property of the object that emits them. and then you use the connect function of that property. Here’s the example using the new style-signals:

from PyQt4 import QtCore
from PyQt4 import QtGui
from PyKDE4 import kdeui

class MyGUI(QtGui.QWidget):

    def __init__(self, parent=None):
        super(MyGUI, self).__init__(parent)
        self.pushbutton = kdeui.KPushButton()
        self.pushbutton.setText("Push me!")
        # New style
        self.pushbutton.clicked.connect(self.button_pushed)

    def button_pushed(self):
        print "Button clicked"

As you can see it’s much clearer, and much more Pythonic. Also, typos will trigger an AttributeError, which means you’ll be able to track where the problem is.

What about overloaded signals? Normally the first defined is the default, but you can use a dictionary-like syntax to access other overloads (signal names are completely made up here):

# One signal is without arguments, the other has a bool

# Signal without arguments
self.my_widget.connected.connect(self.handle_errors)
# Signal with a book
self.my_widget.connected[bool].connect(self.handle_errors)

Signals are emitted with the emit() function and disconnected with the disconnect() function:

# Emit a signal
self.pushbutton.clicked.emit()
# Emit a signal with a value (an int)
self.my_widget.valueChanged.emit(int)
# Disconnect another
self.my_tabwidget.currentIndexChanged.disconnect()

To define new signals, you can use the pyqtSignal function, specifying which values will the signal take (if any): just define that as a class constant (like in the example) and then you can access them like the wrapped ones:

class MyWidget(QWidget):

    # Signal with no arguments
    operationPerformed = QtCore.pyqtSignal()

    # Signal that takes arguments
    valueChanged = QtCore.pyqtSignal(int)

I merely scratched the surface with this. For more information, check out PyQt’s reference manual, which also covers other cases.

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…

It’s been a while since I blogged about anything non-FOSS. This time I’ll be sharing some impressions on one of the games I’m playing at the moment, that is, Ar Tonelico III (which arrived at my doorstep two days ago). I admit I haven’t been a fan of Gust games (aside from Ar Tonelico, they’re known mostly for the Atelier series), mostly because technically wise they didn’t really perform that well. While I understood they’re a small company, sometimes it was a little too much.

I bought this one because from the movies and information disseminated throughout the net it looked like it was better, so I started reading information, which in turn prompted the buy: it’s also a good way to keep my Japanese in order, as I need to keep up with the language if I want to understand things.

Right now I’ve just played a couple of hours, and it looks decent, although with some technical issues (the characters glide over the terrain, rather than walk). I’ve also seen the infamous Purge System in action (look it up online), which made quite a number of fan sneer for a various number of reasons. As of the story, I can’t say anything at the moment: I’ve just started. At least it is moderately fun.

Here’s a hands-on (Italian) which covers more details. I’ll try to post a few updates in the future (if I don’t forget….)

And here’s a quick video I made with my camera:

Click here to view the embedded video.

As most of KDE is C++, and the Python API docs are translated directly from the C++ API docs, it is essential to have good examples to help newcomers learn faster. There are some PyKDE4 examples in the kdebindings module already, but I put mine in kdeexamples for a number of reasons:

• Clear purpose: kdeexamples is meant exactly for this – example code;
• Visibility: A central place to find KDE examples even for bindings is optimal, makes easier to find what one is looking for.

Visibility is also important as currently the examples are rather buried inside kdebindings, and as far as I know they aren’t included in the packages of some distributions (at least not openSUSE; YMMV).

I decided to take this route because PyKDE4 is basically the job of one person (Simon Edwards): he does already a great job, but the work is too much for a single person to handle. And due to shortage of human resources, PyKDE4 lacks examples and documentation, and thus it’s not always easy to understand how to use the C++ API in Python. Writing snippets of working code, with extensive comments, is a step in the good direction. And also an opportunity to contribute back to KDE after all these years!

For now there’s just KConfigXT, but I plan on tackling KIO next, as soon as I have time. Of course, help is welcome!

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…