What’s cooking at the KDE Community Forums?

In the past weeks and days, the KDE Community Forums staff has been working to bring new features to improve even more the user experience. A few months ago, the staff was discussing the idea of finding a way to guide users to the most appropriate forum to post their questions or discussions. Now, thanks also to the return in service of one of our admins (welcome back, sayakb!) the feature is now being implemented, as the screenshots below will show.

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

The world of KIO metadata – checking the HTTP response from a server

Recently, I investigated how to perform some checks on web addresses using KIO for Danbooru Client. My old code was synchronous, so it blocked the application while checking, thus causing all sort of troubles (UI freezing, etc.). Therefore, making the switch to KIO was the best solution. However, I had one problem: how could I check the HTTP response?

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…

Danbooru Client 0.5 is out

Sometimes answering apparently harmless questions on instant messaging can have unexpected results. In particular, I was telling about Danbooru Client to someone and a question popped up "Why don’t you support pages?". It seemed a nice idea, so I branched off the code (yay for git!) and started working on it.

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

Screenshot of the new interface

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…

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!