KDE WebWorld 2011

Yes, unbelievable, i could as well write another “how awesome” post. We decided to try to do a webworld sprint and guess what, we were accepted! So this awesome event will take place and make the KDE webspace an even better place 🙂
For those uninformed, this is a combination of some subteams, which all have related topics in the web. Namely the sysadmins, the docu folks, and and the webteam (for those being curious, yes, indeed, KDE has its own webteam 😉 )
It will take place in germany, essen, the linuxhotel, and i am quite happy about this place, as it transports the right spirit for a sprint like this.
I am also happy that many of the attendees are newcomers, they never were to a sprint, but already showed how valuable they are. Great combination.
So i really hope (and think) this will be a great event.

See you there.

p.s.: promo folks, you are beaten in making a sprint possible 😉

Finding the unloved, 2011, part I

As some of you might already have read, it was time again to find those parts of KDE which projects would need some more love. We (the CWG team) requested input from responsible parties to let us know which those projects are. Now, after 2 weeks we are now sadly announcing those, but on the other hand we are eager to see any help coming in.

So, without any particular order, those are the projects reported to us:

KDE Games

  • The maintainers of several games are inactive, so bug reports pile up. On the code side, KSirk should be ported to Telepathy from its own Jabber implementation to reduce code complexity. Helping hands are also desired in updating the GGZ libraries, which enable networked multiplayer games.

contact kde-games-devel@kde.org or majewsky at gmx.net


  • php, css, html coders needed to maintain kde website infrastructure



  • all kinds of help – The only active maintainer is just trying to plug the crashes and doesn’t have as much time as he did.  He needs someone who can help w/ bug reports/websites/review patches/testing/etc.  No great knowledge of terminals needed for general help.  However, he could use anyone who knows terminals and has time for C++ coding

konsole-devel@kde.org or kurt.hindenburg@gmail.com if you have questions


  • many kinds of help – translations, updating screenshots, adding how-to info, volunteers to undertake agreed maintenance work, adopting specific pages and maintaining them.

contact annew on #kde-www or annew@kde.org

KDE on Windows

  • there are lots of 3rd-party dependencies missing. Also, a lot of applications need Windows-specific bits of code.

contact kde-windows@kde.org

KDE on Mac

  • almost the same as KDE on Windows

contact kde-mac@kde.org


  •  Development:: – KTouch and Kiten are unmaintained, KTouch is a priority while Kiten mlight be scheduled to disapear.
  •  Extract KVTML editor from Kanagram and make it a lib so it could also be included in KHangMan
  •  See if it’s possible to merge KHangMan and Kanagram in one app: first think of a common UI design.
  •  QML use in kdeedu
  • Promo, website: We need more promo work following Code-In submissions: link videos from each app web page, open a page on the website with promo material (logo, usage of logo, t-shirt logo, videos, flyer…)
  • Artwork: Lots of Oxygen icons are missing (app icons, action icons), we need a list of them.

 Contact:kde-edu mailing list (kde-edu@kde.org) and annma@kde.org


  • Picture Frame applet:: support for javascript PoTD providers (maybe even move current ones to js) and for adding/downloading providers with KNewStuff – Clean code.

Contact:: plasma mailing list (plasma-devel@kde.org) and annma@kde.org


  • website updates, bugfixing, testing, integration with the rest of KDE

kde-accessibility@kde.org and/or jpwhiting@kde.org, #kde-accessibility on irc


  • Mostly the same as the last call for arms: they need maintainers for applications such as KFloppy, kdf, sweeper and ktimer (or maybe those could just be removed once and for all). More hands are also needed in Ark  and KGpg (dakon published a blog post some time ago about how he wasn’t very motivated to work on it).

Contact the mailing list (kde-utils-devel@kde.org) or me directly (rakuco on Freenode, kubito at gmail)

If you ask me personally, this list is even too long with only one item, this is far too big. So this is your chance to get involved and get maaany kudos for helping out in one of those areas. If you think your skills could fit or if you are just interested what those tasks would involve just take the necessary step and use the contact details.
Do us a favour and let’s reduce this list to zero!


News from KDE www: pastebin

After a long year of changes in the kde-www land, ranging from looks to scm switches, a final last coup:

KDE is running its own pastebin service now!

What’s special about it, you might want to ask. Several things.
– It is entirely written by our crazy fellow team member Sayak “did i mess up the code again” Banerjee, we have the control over the source, soon to go into git.kde.org
– It is completely ad free (my personal favourite reason for using it)
– It provides the look of the upcoming new kde www look already now, it’s called Chihuahua 2.0
But let’s a bit into the features.
– You can post code snippets, texts, and use syntax highlighting for a nice eye friendly code review.
– You can password protect your code snippets
– You can review previously entered code snippets
– Use RSS notification to get aware of new posts (makes it possible to integrate with an irc bot)
More interesting features are:
– Use the API to post your snippets
– Set an Url dedicated to your project and use this along with your snippets, RSS feeds or archive function, e.g. i just enter the url paste.kde.org/~www/ and welcome to the wonderful world of snippets for our www group.
That should have been all. Wish you have fun with it, use it and spread the word.

What the forums search can do for you

This time i would like to write about a very underestimated feature of the KDE Community Forums, because i am pretty sure most of you don’t even know what it can do for you.

Let’s take a look at it first:

Yes, pretty boring. But let’s see what it can do for you.
First you have the usual search options, like searching for a keyword, an author, and you can of course decide which area of the forum should be searched, or if the whole posts or only titles should be searched. Lastly you can decide the form of the output.
That is the most basic stuff you will find everywhere, still boring.

But some of you might already have noticed, we provide some additional modifications to phpBB.
First, we provide a tagging system. You can assign tags to your topics which then can be searched, either directly on the frontpage (use the tagcloud on the bottom) or in combination with keywords etc. in the search system.
Also, you can mark a certain post as the solution to your problem, which is quite handy, as you can directly jump to the solution from the topic list. But you can also nail down your search results to those topics who provide a solution.

Let’s paint a scenario. I want to have a list of all topics where our insane topscorer administrator/sysadmin Ben Cooksley (bcooksley) wrote something. Result for now 9442 matches. (Soon worth a congratulation btw 😉 )
Let’s nail it down to the tag “system settings”, as he maintains it. There we already are down to 16 entries, 46 if you use systemsettings as keyword instead of a tag. That is mostly because the tagging system is not used as much as it could be. It gets powerful in combination with the search. Consider that next time you visit a topic. Anyone registered can tag.
Anyway, we could now also nail down the above example to solved topics (4 hits) or search in certain areas.

So why could this be powerful?
Well, first, it happens quite often a topic lands in the wrong place, and those who could help won’t find it or it gets overlooked. Having it nicely tagged helps to find it later.
And i don’t need to tell you how much easier searching can be if there are only solved topics shown.

But this is not all. I know the lazy devs, who don’t like websites or forums at all and probably miss important information due to that. Those also can be helped.
See the link in the top bar, which leads you to the rss area. And soon you will notice it is the same interface as the search page. Actually it IS the same, we separated it to make it easier to find the new rss functions.
So everything you can think of you want to search can also be outputted as rss feed. No need to open your browser to get updates, just set up your search and copy the resulting search feed url into your feed reader or irc bot (our does use it already).

Why do i even tell this? Because as you can see it can be really powerful. But to be really powerful both tools, the tagging system and the solved system need to be used more efficiently. Sidenote: Tagging a topic inside the Plasma area with “plasma” is a bit senseless 😉
So go ahead, tag threads and make users aware to mark their problems solved as soon as there is a solution!

Do us a favour and make this search system really powerful


A Matter of Control: The State of Input Device Support in KDE

Guest Post

If you look at the various changes from KDE 3 to KDE 4, two major trends emerge: unification and abstraction. Plasma, for example, unifies the various parts of the desktop and panel. Solid provides an abstraction layer that hides the details of device management from applications, while Phonon does the same for multimedia. Akonadi does both, providing a unified system for handling PIM data and creating an abstraction layer so PIM front-ends don’t need to be concerned with the source or nature of the data they display. And of course the success of KDE 4 is not due solely to these trends, it is also due to developers sitting down and ironing out the current state of the tools in KDE, where they fail, where they work, where they should be, and how we can get them there.

Overall this strategy has proved to be wildly successful. Plasma is now working (at least partially) on everything from cell phones to finance manager applications. The move from HAL to DeviceKit will be pretty much transparent to applications thanks to Solid, and the move from Xine to VLC will be similar for multimedia applications thanks to Phonon.

However, there is one area that I think has been almost—if not entirely—neglected in this process. As you can probably guess from the title, this area is input devices. To clarify, when I say “input devices”, I mean what some would call “Human Interface Devices”. This includes physical hardware like mice, keyboards, remotes, and joysticks, as well as more software-based tools like gesture recognition and speech recognition. For the most part, the state of such devices is largely the same as it was in KDE 3.5. kdelirc has been replaced with kremotecontrol, decent touch-pad support is available, and Simon may one day provide robust speech control, but otherwise not much has changed.

KDE, while on the leading edge of most aspects of computing, has not been for these devices. Some things that have been standard with pretty much every device or desktop environment for years are unsupported in KDE. Even areas where KDE is strongest, such as keyboard shortcuts, there are a number of well-known deficiencies. Attempts have been made to implement certain features, but they have been uncoordinated, inconsistent, and redundant.

In my opinion, the issues related to this aspect of KDE deserve some serious attention, especially with work in many areas of KDE 4 now focused on polish and incremental improvements. Hopefully this article, in which I list some of the problems I see and propose a solution, will get the ball rolling on this front.

I will start by summarizing my take on the state of the major classes of input devices. The details of the problems are not important, the point is to justify my conclusion that the issue exists. At the end I will propose a single solution that I think would solve many of these issues, one that I feel is based off the successes of KDE 4. Unfortunately I am not a developer, so the proposal may or may not be feasible. But at the very least I hope this will at least trigger some serious thought and discussion on the matter.


I would say that the keyboard is easily the class of input device for which KDE’s support is strongest, one of only two classes that I would say actually has good support. That being said, there are a number of issues even here. For example, only one value is allowed for any global keyboard shortcut, and only two for local shortcuts. This makes sense for desktop users, but for laptop users who sometimes use an external multimedia keyboard, they have to decide between using their multimedia keys or having shortcuts that work while traveling. If you use Bluetooth remotes, which tend to be identified as keyboard buttons, this is an even more serious issue since the buttons on the remote may not correspond to those on your keyboard, meaning you can only use one or the other. And amongst the multimedia keys my version of x11 supports, KDE trunk currently cannot recognize 20 of them, about 13% of the total number.


This is the other area where I think KDE support is good, although not as good as with keyboards. There are two primary problems I see with the kremotecontrol. First, it requires that the remote already be configured, not necessarily an easy task and one that generally requires fiddling with the command-line and editing text files. Second, it requires an implementation of a shortcut system completely independent from the keyboard shortcuts. This involves a separate and very different user interface to accomplish roughly the same task, and requires that either individual applications or kremotecontrol provide a second, redundant set of commands. Since remotes are nowhere near as common as keyboards, this has left kremotecontrol with far fewer applications it can control directly and far fewer commands it can issue. It is capable of mapping remote control button presses to D-Bus events, but this is very complicated and requires the target application be running.


KDE’s support for mice, or lack thereof, is for me its most glaring deficiency. For a device as ubiquitous and essential as mice are, they have gotten remarkably little attention from developers. One of the more obvious limitations in KDE’s mouse support is the lack of support for now almost universal back and forward buttons. You would be hard-pressed to find a mouse today, even small, budget, portable, laptop mice, that do not have these buttons. As far as I am aware every modern desktop environment supports these buttons besides KDE. Even Apple, which long resisted even the right-click, now seems to support these buttons. Many mice today, especially high-end mice, have many more buttons than this. Besides the normal three buttons+scroll, my mouse has seven extra buttons, none of which work with KDE. There is no general way to use mouse button presses or combined keyboard and mouse button presses for use as shortcuts. These sorts of things are possible to implement in KDE, rekonq supports back and forward buttons while plasma supports combined mouse/keyboard shortcuts (although only local shortcuts, not global ones), but there is no general, KDE-wide way to use these buttons, the support that does exist is only in one or two applications, and for most buttons there is no solution in KDE at all. Feature requests for better mouse button support are amongst the oldest, highest-voted, and most-duplicated wish-list items in both bugs.kde.org and the KDE brainstorm system.


KDE’s touch-pad configuration has greatly improved recently from a basic configuration standpoint. However, it suffers from the same limitations as mice, namely that there is no easy way to map touch-pad events to commands. There are four corners in a standard rectangular touch-pad, but KDE only lets you map the three mouse buttons, wasting at least one corner (or more if you have a multi-touch enabled touch-pad). There are four edges, but only two ways to scroll, meaning edge actions commonly seen in other touch-pad configurations, like back/forward and volume control, are not supported. With two directions per edge and four edges that is eight commands. With circular scrolling, there are two additional directions for each edge and each corner, giving 16 additional shortcuts. With multi-touch enabled touch-pads all of those could be used for non-mouse-related tasks. That is 28 potential commands on every touch-pad. That many is probably too much for users to remember at one time, but it is a lot of untapped capability, much of it capability that has been present in pretty much every touch-pad driver in windows for at least five years.


Joystick support in KDE is also pretty limited. You can calibrate your joystick, it shows the current values for each button, and it shows a trace for two axes (no matter how many axes the joystick actually has). There may be some joystick controls in some games (although I wasn’t able to find any, even for games where it makes sense). Ignoring games, however, many joysticks provide a half dozen or even a dozen buttons and often at least four or five axes, all of which could be put to good use as shortcuts for controlling your computer. In fact many joysticks come bundle with tools that let you do this in windows, and it is probably even more useful for game pads which are smaller, easier to handle, and often wireless.


I already mentioned the issues with Bluetooth remotes and keyboards. Less-standard devices, like Nintendo Wii remotes, currently need separate software to interpret them, and they have to be mapped to other input devices like keyboard button presses in order to be used. There are some efforts to get native support for these sorts of devices, such as in Plasma Media Center, but once again these solutions are restricted to parts of KDE and thus will not help KDE as a whole.


KDE has support for mouse gestures. However, the configuration of these gestures is difficult, relying on the custom shortcut system which then forces you to map the gestures to keyboard shortcuts or D-Bus commands.

Speech Recognition

Simon should provide speech recognition support, but since I have never been able to get it run, and it does not compile at all with Qt 4.7, there is not much I can say. I don’t expect the situation to be much better than with kremotecontrol, though.

A Proposal

As I mentioned at the beginning, I think unification and abstraction have proven to be extremely successful in KDE wherever they have been applied. So the questions are, can these approaches be applied to input devices, and will this make users’ and developers’ lives better? I think the answer to these questions is “yes”.

KDE already has a really good D-Bus-based system for handling input events. This is the keyboard shortcut system I mentioned earlier. It makes it very easy to assign keyboard shortcuts, and automatically provides slots for keyboard shortcuts for any toolbar button or menu entry without any additional effort by developers. However, the interface would work just as well for shortcuts involving other input devices. In fact, almost identical user interface elements are used by Plasma for mouse shortcuts.

So I think the best solution would be to build off the existing keyboard shortcut system, extending it so developers can write plug-ins that provide support for additional types of input devices. The plug-ins would send events to the shortcut system in a standard format. The shortcut system would then combine the events from all the plug-ins and pass those events along to applications. Applications would just see these generic input events, they wouldn’t need to know or care what sort of device sent them (although I suppose this information could be provided if it would be useful).

This approach has a number of advantages over the current implementations:

  1. Users don’t have to map input events to keyboard shortcuts
  2. Users don’t need to go searching for the right tool to configure a device
  3. Users don’t need to learn several different configuration interfaces
  4. Developers have a consistent software interface for all devices
  5. Application developers don’t need to change anything in their applications
  6. Developers don’t need to write a custom user interface just for their device
  7. If one developer programs support for a device the rest of KDE gets it for free
  8. Support for shortcuts that combine two devices, like mouse+keyboard shortcuts, would happen automatically
  9. Plug-ins would not need to be tied to physical hardware devices, so for example a program that triggers a particular event at a particular time would be easy to do without needing to worry about cron jobs or shell scripts
  10. Joystick support for games would happen automatically (at least for buttons)
  11. It should make it easier to keep up with changes in underlying libraries, like x11 keyboard keys
  12. It would be easy to package and distribute plug-ins
  13. It would be easier to support additional operating systems
  14. Plug-ins could be loaded only when the appropriate device is connected
  15. It could be possible to support multiple plug-ins for the same device with different features, although this may not be desirable

One objection may be that there are major differences between different input devices. For instance kremotecontrol supports profiles, which allows you to change the role of each button. However, this turns out to be a benefit of this system, rather than a drawback. It allows developers to focus all their attention solely on the things that are different about the device they are working on. Each device would still need configuration tools to configure properties that are unique to that device, but they can share configuration tools for things they have in common.

So in the case of kremotecontrol profiles, rather than having to worry about mapping the button presses in different profiles to different application events, all the developers would need to do is let the users assign whatever name they want to the buttons in each profile. The same name would be seen by the shortcut system as the same button. If you want a button to do the same thing in different profiles, give it the same name. If not, give it a different name. If you want different buttons to do the same thing, give them the same name.

However, you could even take it a step further. Being able to configure different sets of shortcuts for different situations could be very helpful, maybe even tied to activities. So the kremotecontrol developers could, if they wanted, integrate their profile system into the shortcut system as a whole. That is another advantage of this system: if there is a useful feature, all devices could benefit from it rather than just one.

There is one thing that would still need to change in the shortcut configuration, though. With all of the devices being supported in a single interface, one global shortcut and two local shortcuts per command would no longer be sufficient. Users would need to be able to set an arbitrary number of global and local shortcuts for any command. As I explained earlier, however, I think this is a worthwhile change in and of itself, so I don’t consider this to be a disadvantage.

In the end, this is just an idea about how the sorts of approaches that have worked in other parts of KDE could be applied to input devices. But this is not intended to be the end of the discussion, rather I hope it is a starting point. A sprint dedicated to input devices would be ideal, but I think any sort of focused attention on this area would be of great benefit to KDE. I think that if KDE developers put their heads together and work some of their magic they could make KDE’s input device support second to none, as they have done with many other areas.

by Todd

projects.kde.org got a facelift

Some of you might know, i am always trying to improve the experience of our KDE websites. Last improvement was Userbase (if you don’t know that yet, go and visit it!).

Now we have a new facelift. Some might have seen it, projects.kde.org is now our project management facility. But its look was a plain default redmine one.

But with some help of our artist Eugene Trounev we were able to change that. So take a look. Hope you all enjoy it and still find it usable.

Amarok & Translations

First, some of you might know we are using a new mediawiki extension at Userbase, namely the Translate extension by the translatewiki folks.
It is an awesome extension making us able to translate content on- and offline via po files. Those guys are really helpful with any issue we encounter and they deserve a hug whenever you meet them 😉

Now, Mamarok and Valoriez of Amarok fame stepped up and wrote a very nice Quickstart guide for Amarok on Userbase. And in my opinion, this is a good time to take our new extension to its limits.
The guide is now marked for translation and everybody could step up and translate it to his/her native language. You only need to have a registered account at userbase and add yourself on http://userbase.kde.org/Translator_Account
Then you can be added to translators and start your work.

The reason i write this is simple. Have as many translations as possible. KDE itself has now translations for nearly 100 languages (if i didn’t count wrong). And having those for userbase, too, would be just plain awesome. Or do you know any other wiki with so many languages? If so, please tell me.
Another reason is, you could give me a hard time 😛
Notice the language bar above every article. Not that bad with a handful of languages. But consider it a box with links to a hundred and more languages… I would need to find a better way to display the language list. And as there is a new theme about to come it makes sense to fix it before 😉

So, put some stress on me and translate as much as you can from this quickstart guide. For guidelines you can see the sidebar links on Userbase or ask us on #kde-www (freenode).

Git needs YOU

This is as a reminder of those out there who still didn’t convert their account from https to ssh:

Yes, there are still many accounts left to convert, as toma already pointed out. We, the sysadmins really want to get this rolling, so go ahead and answer our invitation mail. You know who you are, you must have got it 😉

Get Involved

Once i have read comics, many comics. Especially those of some superheroes. What i can remember quite well is one comic about superman. It was about a problem with our parallel world. Suddenly there were 2 earths. And Superman’s problem was now to put those 2 worlds together again. To keep it short, he was actually able to handle it. Why do i want to tell this?
What we actually have are 2 different worlds.

The first one is that of a user willing to contribute but not knowing how and where. Maybe it also involves being a bit shy, maybe just not finding the right information or the right place.

The second world is the developers world. They work hard on their product and have a hard time to do it all, always waiting for a new volunteer.

Now, how could these two worlds be approached? Afterall, we want our small family called KDE grow, right? 😉
That’s where “Get Involved” comes into the game.

It is an open call to users who have a special love for a certain project of KDE and would like to contribute.
All of those projects need someone looking after bugs, some promo work or maybe just talking about it. Something everyone could fullfill.
This user will be mentored to get in contact with the projects developers and keeping up with the information needed.
He/She will keep up with new features and how to work with them and probably talk about them in the various communication channels.

This is basically not new, KDE is, like any other open source project, open to every new contributor. What is new though, is to give them a real guidance on the way to it. It is especially important to give them a real list of small tasks that need to be done and point them to it.

Now, there are the klassrooms, which are seeing daylight again. But that is not enough. I see the need to have a coordinated effort to invite new contributors, be it just plain users willing to help out their favourite application or project.

Mentoring can be done on various ways. We could open a dedicated irc channel, but of course also the forums can help with that. A place where mentors and volunteers can exchange questions and ideas. It would be like the bridge between the above two worlds.

So, for any project out there, if you see a need for that, if you want some more support, give me some feedback.

What sort of help does a project need from a user?
– bug triaging (it is much easier when concentrating on just one app)
– writing documentation
– spreading news about new functions or workflows
– testing updates
– what else? (tell it to me)

KDE BugWeeks

Yes, the title is weird, you probably know it as BugDay. So why did i write this? Well, after some discussion about a possible klassroom about bughunting we decided to dedicate a full new section to bughunting. Why? Bugs are everywhere, no matter which area. That is sad. But hunting them down is fun actually.
Just think of how fun it would be if you would be able to close a bunch of those bugs. And you always thought it would be that hard. But it isn’t! That’s why we now try to join the bugsquad team with the forum team.
That means, preparation will take place on the forums, and the final bugday (like you know it) can take place on both, the forums and irc.
You will get the help you need to set up your environment and be ready to invest bugs.
Want more info? Visit this topic.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.