KDE Blogs 

The month of May has started with a big milestone: the approval of the OpenDocument 1.0 specification as an OASIS standard. Part of the credits for that go to our very own David Faure who has done a great amount of hard work in the OASIS OpenDocument Technical Commitee. The importance of a truly open file format for office documents can not be understated and the OASIS OpenDocument standard helps to bring competition back to office applications. I expect the OASIS OpenDocument standard to make headlines in the near future as it has been eagerly awaited by governments around the world. Read More

I just had a problem with Knowledge, which as you might know, is my attempt towards a Wikipdia offline reader: I needed to disable lots of GUI stuff in my QMainWindow-derived class as long as no offline image is loaded. Some of the widgets werent even available as object members. All widgets need to be deactivated and then activated again after the book was loaded. The obvious choice would have been to add a bunch of members, one for every object in question, and then call setEnabled( true ) or setEnabled( false ) for each of them respectively. Result: lotsa code. Lotsa members, sucks. So what was my solution? Obviously, all relevant classes in this case are really QWidgets (except for QActions, I'll get to them later). So what I did is having a private member QList < QWidget* > mStateWidgetList. Every time a widget shows up I would add it to the list. Tackeling a bunch of them is just as easy: Read More

Dave Hyatt asks this question in his blog. First of all let me just say this: KDE developers who worked on KHTML are simply really attached to it because historically it was the "rendering engine done right" and for people who worked on it, well, it's their baby. Read More

So over the last few weeks I have started work on the new KJSEmbed that will be in KDE 4. In a change of heart that is an entirely different blog all together I have decided that I will push to have KJSEmbed in the core of KDE 4. Read More

Today, Fab confirmed my accommodation for the KDEPIM meeting in Achtmaal, Netherlands. There are at least three reasons why I'm really happy to go there: "Speaking Usability" During the last two or three weeks, I've spent a lot if time thinking about how to facilitate the usage of Kontact for less experienced users. Cornelius, Danimo and me discussed some ways, and I finally managed to create a few screenshots and wrote explanatory lines. The problem with such usability proposals is that they are mostly too long - so every developer pitches on the sections that are of concern for him. But without reading the whole document, the context does not become clear and some suggestions simply seem to be stupid =| And even if everybody agrees with the suggestions, they often do not fit in the current project plan and after a few months they are obsolete or forgotten. Meeting each other and "speaking usability" face to face is the best way to avoid this =) Visiting the Netherlands Well, I haven't been there for at least five years!! After the KDE meeting, I'll straightly head to the sea, lie down in the dunes, and enjoy being there *happyness* Seeing some of you guys Lastly, I'll see some of you guys. Always a good reason to travel a few hundred kilometres =)

The comic foxtrot is always really nice to read; and todays comic was showing the common problem of more features meaning less usability in a very clear way; I can't help but talk about it (well, after I stopped laughing :) First here is the comic: The author (correctly) got just about all the big usability rules wrong to make sure this thing display power (its huge!) but be quite useless at the same time; I wrote this down a long time ago in the UI guidelines. To be user friendly, software must be: task-suitable, understandable, navigable, conformable to expectations, tolerant of mistakes and feedback-rich. (follow the link above to get a full explenation) Read More

The Ubuntu Down Under conference is now closed. Mark gave some closing thanks which I noted down, again completely un-proofread and spellchecked. Finally on the last day I found a fellow KDE coder. sebr the elite Amarok hacker. Jeff Waugh explained how #gnome-hackers had been laughing at the scary Amarok setup wizard, I'd like to get rid of that for Kubuntu, infact if Amarok could be simplified by default and keep the fancy features for those who want them that would be great. Read More

KDEPIM meetings appear to be successful for the progress of KDEPIM/Kontact. So the Dutch local KDE group, KDE-NL, decided to organise such a meeting as well. For this we needed money. Although KDE-NL has some budget of its own it was clear that we needed some extra money for funding the accomodations and for some people help them pay for the travelling costs. Read More

Qt4 is really progressing well. The only problem at this point is that it still changes a lot even after Beta 2 which originally meant to end the phase of rather radical changes, according to the trolls. But that's fine. Let them get their APIs sorted out, let them react to the extensive feedback and let them time to do it right. So what's new in Qt land since Beta 2? First thing to notice is the introduction of "Plastique", which is, as you certainly suspected already, a Qt-only version of the KDE 3.4 default theme "Pastik". The clear advantage is that Qt finally has a decently looking style for Linux, which is available even to statically-linked Qt applications. This is good since I never liked the rather sharp-edged windows style mixed with rather smooth styles like Plastik. The next topic is an improvement (at least I suppose it's new, Maksim wasn't sure either) regarding tool windows handled by QWorkspace (aka MDIs). The window decoration is now completely under control of QStyle, and it might be possible to implement a bridge in KStyle that maps the current KWin decoration on a KDE Style for MDI Widgets. That said, Maksim warned me that it would be hard to do, so I don't take that for granted. Anyway, Plastique provides a nice (hardcoded) Plastik Window decoration, you can get a good impression on how things could look like in the future. Oh yeah, and another one: It will be possible for Qt-only application to make use of at least parts of the KDE icons now. Qt has a standard icon set, which depends on the style. KStyle can map them to KIconLoader, or whatever its equivalent in KDE 4 will be called. Ideally everyone is going to use KDE libs for all platforms once the Qt4 port of the KDE libraries is done and available for all major platforms (Unix, Linux, OS X, Windows) even for Qt-only apps, but we will see if that is going to be accepted amongst Qt developers. Anyway, this will work in any case :). Designer started to get a usable resource editor component. Qt4 resources obsolete the qembed concept of Qt3, making things significantly easier: Simply add files in the editor (i.e. graphics), i.e. /images/mypic.png. Add the resource file to your Qt project and run make. Qt will handle the rest for you. Accessing the resource e.g. from within richtext is as easy as label->setText( QLatin1String( "... ; ..." ) ); The richtext engine itself still has some bugs, but I'm confident they'll get sorted out soon. That's today's little Qt4 tour. We hope you had a pleasant trip!

I found this great little ruby program on isaac's random rants blog - it takes the contents of the klipper clipboard, sends it to rafb.net which is 'code snippets temporary storage' site. You put your clipping there, and it returns you the URL back on the clipboard that you can paste into an IRC channel or whatever. I added a 'lang=Ruby' attribute too so the snippet gets labelled as a Ruby one. Read More