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…

It was a mostly painless process, mostly because I was too fast, and the mirrors hadn’t synced yet, so I ended up with 4.3.77 packages instead of 4.3.80 (Beta 1). I just avoided to log into X and waited till the right packages were available, then I updated again. I updated system-wide (yes, I can be that crazy) and I started using the beta (and its subsequent snapshots) full time. In part it’s because I’m a feature addict, in part because I wanted to write some promo material (I’m really sorry Jos, I didn’t find the time to do it yet!) to make things easier prior to release.

So, how’s the SC faring, so far? Pretty nice, overall. There are of course quirks (for example KWin not responding to global shortcuts unless it’s restarted), but generally the experience has been quite positive. The user-facing components, such as KWin and Plasma, have improved quite a bit (new effects, the new widget explorer, new applets….), but also less visible parts such as Nepomuk (with the Virtuoso backend it works OK, although for some reason I can’t access the metadata panel in Dolphin or use the search, also in Dolphin). I also took the time to explore other applications, for example Cantor, as I’m a (reluctant) user of the R programming language. The version built by openSUSE doesn’t ship with an R backend, so I had to compile it on my own. It is more minimalistic than, say, rkward, but I can foresse already some uses for it (especially running already-made scripts).

I also tried out the netbook shell on my Eee. Again, it’s pretty nice, although sometimes the performance is still lacking (but my Eee uses an i915 chipset, so it’s really the end-of-line and may have played a role in this.

Overall I’m very impressed, so congratulations to everyone who’s making this possible!

Lastly, following up what Stuart and others did, here are two screenshots of two of my (many) activities (click for full picture):

]]> http://www.dennogumi.org/2009/12/living-on-the-edge/feed 19 http://www.dennogumi.org/2009/11/after-a-hiatus-klassrooms-continue http://www.dennogumi.org/2009/11/after-a-hiatus-klassrooms-continue#comments Sun, 29 Nov 2009 22:25:34 +0000 Einar http://www.dennogumi.org/2009/11/after-a-hiatus-klassrooms-continue Do you like KDE? Did you ever find yourself in a position of wanting to help, but you didn’t know what to do, or who to talk to? Do you feel you could use help to get started?

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.

Danbooru? Is it something you eat?

Well, aside from the Wikipedia link above, I think a small introduction is in order, at least for the readers coming from PlanetKDE. Danbooru is a kind of image board which structures its data semantically, by having tags attached to images (along with other things, such as favorites, rating, etc.). It can be browsed normally (newest posts, etc.) or by using tags and other properties. Some boards are quite popular in the anime-viewing community. The neat thing about Danbooru (which is by itself a Ruby on Rails application) is the fact that it can provide a REST and POST API to access data. So. it’s technically possible to access such boards programmatically: the API permits not only retrieving posts, but also upload, tag, and perform other operations.

The API could be technically used also for client applications, in order to free the user from using a browser. That is what Danbooru Client is aiming to do.

Introducing Danbooru Client

Danbooru Client fits exactly these needs by providing a GUI to (part of) the Danbooru API.

Features:

• Connect to any Danbooru board (three predefined)
• Download up to 100 images with selectable tags;
• Download or view images with the KDE preferred image viewer;
• Tag semantically the images using Nepomuk.

Requirements:

• PyQt (at least version 4.5)
• PyKDE4 (tested with PyKDE 4.3 only)
• (optional) Nepomuk
• Python (at least version 2.5)

Screenshots

(click to enlarge)

Download & Installation

You can obtain Danbooru Client from kde-apps.org. For the bleeding edge people (but are there such users for such an application?) there is a git repository set up at Gitorious. Once downloaded, you need to use CMake to install the files. Unfortunately due to the way CMake is set up, you’ll need the KDE development headers and a working C++ compiler, even though you won’t need them for the installation.

The installation process is very straightforward:

cd /path/to/source
mkdir build; cd build
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ../
make # This just byte-compiles Python files
sudo make install

Then, just launch “danbooru_client”.

Known limitations

There are plenty for now, it’s just version 0.1:

• Zero documentation (although it’s kind of straightforward to use)
• Empty cells are created when a row is not filled with images
• No support for multi-download
• Untested login/password access
• The interface may be horrid
• Danbooru does not support rating filtering via API, so it’s not currently possible to do so

The client is licensed under the GPL v2 or later. The artwork for the splash screen is also under the GPL and was made by Melissa Adkins.

• KConfigXT requires an XML file and an INI-like file to be compiled by kconfig_compiler in order to produce C++ files
• There is no such a tool (at least to my knowledge) that does the same job for bindings

So what to do? Either give up on the niceness of KConfigXT, or work around the issue. I chose the latter.

Bypassing the kconfig_compiler limitation

What kconfig_compiler does is basically generate the KConfigSkeleton sublcass needed for KConfigXT. So, we can create our own subclass by hand: a little more work is involved but nothing too hard. The following snippets, taken from a GPL application I’m working on, will demonstrate how to do it.

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyKDE4.kdeui import *

#UI stuff - see later
from ui_generalpage import Ui_GeneralPage

class Preferences(KConfigSkeleton):

    """Class to handle preferences."""

    def __init__(self, *args):
        super(Preferences, self).__init__(self, *args)
        self.setCurrentGroup("General")
        self._danbooru_boards_list = QStringList()
        self._danbooru_boards = self.addItemStringList("danbooruUrls",
                                                       self._danbooru_boards_list,
                                                       QStringList())

Here we set up a KConfigSKeleton subclass. The first thing we set up after that is the config group we want to use: we can have several, for example “General”, “Services”, and so on. Of course an empty group makes nothing, so we populate it, in this case with a QStringList configuration item (see the API docs (KCoreConfigSkeleton, but KConfigSkeleton is a subclass of that) for more types you can use). You’ll notice that we assign an empty QStringList to a variable, which is then used in the addItemStringList call later. That’s because KConfigSkeleton (in C++) wants a pointer to the type of content, and since in Python we don’t have pointers, we pass a reference (and by binding it to our class instance, we make sure it won’t be garbage-collected).

The addItemStringList (and other addItem*) methods use three parameters: a string with the name of the option (remember this!), the reference to the item, and a default value (in this case an empty QStringList).. Once we’ve set the options, we call readConfig() in the initializer to make sure the values are read from the config (or default values created).

I set all the attributes as “hidden” to prevent direct manipulation. To access them, I set up properties (following the example of minirok, another PyKDE4 application).

    @property
    def boards_list(self):
        return self._danbooru_boards.value()

As you can see, the value of the configuration items is accessed via the value() function. Once tihs is done, we’re done with regards to the KConfigSkeleton part.

KConfigDialog

Of course now we want to create the config dialog. We do so by subclassing KConfigDialog. First, though, we must create the page contents. We do so in Qt Designer. We first create a widget, and then we place our configuration widgets on it. It is essential that the widget that will store our configuration details have the name kcfg_CONFIGOPTION, where CONFIGOPTION is the name you specified as a string in the KConfigSkeleton initializer. Once done, we save the ui file, compile with pykdeuic4, we set it in the imports of our preferences file and we’re good to go.

The following is an example of a general configuration page widget (the UI_* is the pykdeuic4 generated file):

class GeneralPage(QWidget, Ui_GeneralPage):

    def __init__(self, parent=None, preferences=None):
        super(GeneralPage, self).__init__(parent)
        self.setupUi(self)

        self.kcfg_danbooruUrls.insertStringList(preferences.boards_list)

As you can see, we pass the preferences instance in the initializer, so we can populate the widgets (which are indeed named kcfg_danbooruUrls, just like the config option I set earlier) . Of course you can connect signals and whatnot to slots in case you want to do something with your widgets. I didn’t have the need, so no need to.

And once we have this set up, we can finally create the KConfigDialog!

class PreferencesDialog(KConfigDialog):

    def __init__(self, parent=None, name=None, preferences=None):
        super(PreferencesDialog, self).__init__(parent, name, preferences)

        self.setButtons(KDialog.ButtonCode(KDialog.Ok |KDialog.Apply |
                                            KDialog.Cancel))

        self.general_page = GeneralPage(self, preferences)
        self.general_page_item = self.addPage(self.general_page, 'General')

In the initializer, we pass the preferences instance, the name (used later to determine if a page is already open, since KConfigDialog is non-modal), and of course, the parent widget. We then set the buttons (using bitwise ORs) we want to show. Finally, we instantiate our page widget and add it to the dialog, specifying a name that will appear on the side. Using the setIcon method you can also set an icon for your page. In case you want to perform checks and other things, reimplement slotButtonClicked in your subclass with (self, button) as parameters. But dont’ forget to call the original KConfigDialog.slotButtonClicked(button) in that case.

Wrapping it up: calling KConfigDialog

Finally, how to call your dialog? First of all, you need to instantiate your preferences object, for example in your main window application code:

self.preferences=preferences.Preferences()

Then, in your code, you do something like this:

if KConfigDialog.showDialog("Preferences dialog"):
    return
else:
    dialog = preferences.PreferencesDialog(self, "Preferences dialog",
                                           self.preferences)
    dialog.show()

The first if ensures that if there is already one dialog open, it won’t open another. If that’s not the case, we instantiate the dialog, passing it the name (which must be the same as the if above), the parent, and the preferences instance.

Voila’. In the end, you’ll get something like this (slightly different):

I know my own UI sucks here, but it’s something I’m still experimenting…

For this tutorial, thanks go to Pino “pinotree” Toscano, who pointed me to the “minirok” project, which makes use of KConfigXT, and Adeodato Simò, the author of minirok.