Yesterday I blogged there were 4 days left. Today there are 5 days left: Google extended the deadline to March 26th.

So you now have the weekend to finish your proposal. But I still would like to see submissions earlier than that.

So this is the time to send your proposal if you haven't already. If you want to work on something for KDE 4, you're a student and would like to get paid, this is your chance.

You still have 4 days (and a few hours) to send it using the Google web interface. It closes for new submissions on March 24th, 23:59 UTC. After that, you will have to wait for next year and KDE 4.0 will already be out.

With 4 days to go, we're still nowhere remotely close to the application count of last year. Then again, last year, I was also very surprised when the gross of the applications turned up in the final days. I recommend students not to wait: your application doesn't have to be perfect, just good enough. And, besides, applications sent early get more review and, probably, more votes.

It's so weird to start writing Yet Another Networking Framework (YANF) for KDE...

It's weird not because it's simply YANF. It's weird because this is the fourth networking framework that I will have written for KDE. So, a little history:

1. KDE 1.0 came out with a KSocket and a KServerSocket class, by Torben Weis
2. During the KDE 2.0 development phase, I started to write something different, to support IPv6. This never made it to mainline KDE because I did not submit it. But here's the proof that I did: my blog from Aug 17th, 2000
3. Later, when KDE 2.2 was in development, I started to write the KExtendedSocket class, that actually made it to the release. Here's the blog from Dec 2nd, 2000 to prove
4. As a general consensus, KExtendedSocket was found to be bloated and difficult to understand. So I proposed a new framework, simpler and more robust. In fact, I proposed that it become part of Qt, but that didn't happen. Nonetheless, it did influence Qt 4's QtNetwork library. But it turned out to be the current KNetwork framework in kdecore. Here's the blog showing me starting to work and the initial proposal email from Jan 14th, 2003
5. After Trolltech announced support for proxies and SSL in QtNetwork last week, I decided it was time to merge KNetwork and QtNetwork (one could say they are two children of the same idea, above). So, I sent this email entitled "RFC: Drop notice: KNetwork" to kde-core-devel

The new framework will be basically a wrapper around QtNetwork to provide the two missing features: Unix sockets and SVR-based lookups. The rest we can do without. And even then, Trolltech seems to be interested in providing Unix sockets in QtNetwork itself.

Yeah, the Title of this blog sounds like a job opportunity... but that's intentional. I am proposing a job opportunity -- in the FOSS style

When discussing with Aaron Seigo tonight about some old functions in KApplication that we wanted to move or remove from KDE4, we came up with the conclusion that we instead needed a new class. We've called it KAutoSaveFile and its purpose is to allow application writers to easily:

• Write unsaved data to a temporary file, in case the application crashes or the power goes out or something drastic like that.
• Determine if there is such unsaved data left behind and offer the user to recover it.

Fairly simple, eh? Well, we'd like to have someone to do that for us. Someone fairly motivated by open source and KDE, with good knowledge of C++, preferrably someone who isn't already a KDE core developer (knowledge of the KDE library policies is certainly welcome). I'll be coaching you and helping you along the way with my own ideas about this. Think of this like a very short Summer of Code or Season of KDE. But without any money.

And to kickstart this little adventure, we've already prepared the header file for the class! All you have to do is write the .cpp file for it.

If you're interested, just let me know.

It's been quite a while since I've blogged. You know, life gets in the way...

But this is a good time as any to say it: Happy Birthday KDE. May the next 10 years be more groundbreaking and memorable than the last 10.

Congratulations for everyone involved. We have come a long way since Matthias' original post on USENET.

This morning, Trolltech released the Technical Preview 1 for Qt 4.2. Along with the many long-awaited features, you can even find the QtDBus module as part of the standard release.

Yes, yes, I know they're mad

I am sorry I had to keep the suspense of whether it was going to be included in the release.

IMO, this is quite a support for D-BUS. I believe that D-BUS will come to play a big role in the future of the Linux/Unix desktop, which is why I asked and was granted permission to work on it.

So, there it is. I await your feedback.

So I was working on kdelibs over the weekend, trying to clear up a few problems with the D-BUS implementation in KDE. I found that the KMainWindow interface worked almost perfectly out of the box (it would have worked perfectly if I hadn't used a dash [-] in the object path in the first place).

Here's what the object looks like: [image:2079 hspace=10 align=right class="show-on-planet" size=preview]

$ dbus local.kmainwindowtest /kmainwindowtest/MainWindow_1
method void local.kmainwindowtest.KMainWindow.appHelpActivated()
method void local.kmainwindowtest.KMainWindow.configureToolbars()
method void local.kmainwindowtest.KMainWindow.setCaption(QString caption)
method void local.kmainwindowtest.KMainWindow.setCaption(QString caption, bool modified)
method void local.kmainwindowtest.KMainWindow.setPlainCaption(QString caption)
method void local.kmainwindowtest.KMainWindow.setSettingsDirty()
method void local.kmainwindowtest.KMainWindow.slotStateChanged(QString newstate)
method void local.kmainwindowtest.KMainWindow.slotStateChanged(QString newstate, bool reverse)
property readwrite bool com.trolltech.Qt.QWidget.acceptDrops
property readwrite QString com.trolltech.Qt.QWidget.accessibleDescription
property readwrite QString com.trolltech.Qt.QWidget.accessibleName
property readwrite bool com.trolltech.Qt.QWidget.autoFillBackground
property readwrite bool com.trolltech.Qt.QWidget.enabled
property read bool com.trolltech.Qt.QWidget.focus
property read bool com.trolltech.Qt.QWidget.fullScreen
property read int com.trolltech.Qt.QWidget.height
property read bool com.trolltech.Qt.QWidget.isActiveWindow
property read bool com.trolltech.Qt.QWidget.maximized
property readwrite int com.trolltech.Qt.QWidget.maximumHeight
property readwrite int com.trolltech.Qt.QWidget.maximumWidth
property read bool com.trolltech.Qt.QWidget.minimized
property readwrite int com.trolltech.Qt.QWidget.minimumHeight
property readwrite int com.trolltech.Qt.QWidget.minimumWidth
property read bool com.trolltech.Qt.QWidget.modal
property readwrite bool com.trolltech.Qt.QWidget.mouseTracking
property readwrite QString com.trolltech.Qt.QWidget.statusTip
property readwrite QString com.trolltech.Qt.QWidget.toolTip
property readwrite bool com.trolltech.Qt.QWidget.updatesEnabled
property readwrite bool com.trolltech.Qt.QWidget.visible
property readwrite QString com.trolltech.Qt.QWidget.whatsThis
property read int com.trolltech.Qt.QWidget.width
property readwrite QString com.trolltech.Qt.QWidget.windowIconText
property readwrite bool com.trolltech.Qt.QWidget.windowModified
property readwrite double com.trolltech.Qt.QWidget.windowOpacity
property readwrite QString com.trolltech.Qt.QWidget.windowTitle
property read int com.trolltech.Qt.QWidget.x
property read int com.trolltech.Qt.QWidget.y
method bool com.trolltech.Qt.QWidget.close()
method void com.trolltech.Qt.QWidget.hide()
method void com.trolltech.Qt.QWidget.lower()
method void com.trolltech.Qt.QWidget.raise()
method void com.trolltech.Qt.QWidget.repaint()
method void com.trolltech.Qt.QWidget.setDisabled(bool)
method void com.trolltech.Qt.QWidget.setEnabled(bool)
method void com.trolltech.Qt.QWidget.setFocus()
method void com.trolltech.Qt.QWidget.setHidden(bool hidden)
method void com.trolltech.Qt.QWidget.setShown(bool shown)
method void com.trolltech.Qt.QWidget.setVisible(bool visible)
method void com.trolltech.Qt.QWidget.setWindowModified(bool)
method void com.trolltech.Qt.QWidget.show()
method void com.trolltech.Qt.QWidget.showFullScreen()
method void com.trolltech.Qt.QWidget.showMaximized()
method void com.trolltech.Qt.QWidget.showMinimized()
method void com.trolltech.Qt.QWidget.showNormal()
method void com.trolltech.Qt.QWidget.update()
method bool org.kde.KMainWindow.actionIsEnabled(QString action)
method QString org.kde.KMainWindow.actionToolTip(QString action)
method QStringList org.kde.KMainWindow.actions()
method bool org.kde.KMainWindow.activateAction(QString action)
method bool org.kde.KMainWindow.disableAction(QString action)
method bool org.kde.KMainWindow.enableAction(QString action)
method void org.kde.KMainWindow.grabWindowToClipBoard()
method qlonglong org.kde.KMainWindow.winId()
method QString org.freedesktop.DBus.Introspectable.Introspect()
method QVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QVariant value)

The local.kmainwindowtest.KMainWindow interface is a side-effect I'll have to correct eventually: I wanted to get all the QWidget slots public, but that also made the KMainWindow slots public as well.

With that object, you can do nifty things like raising, lowering, minimising, restoring, hiding or showing a window, setting it to full-screen and normal mode or even copy it to the clipboard. Unfortunately, you can't move windows yet, because the geometry and pos properties take QRect and QPoint (respectively), which aren't supported in D-BUS for the moment.

This is all cross-framework as well!

Here's what the /MainApplication object currently looks like (it's the KApplication object):

$ dbus local.kmainwindowtest /MainApplication
method void org.kde.KApplication.quit()
method void org.kde.KApplication.reparseConfiguration()
method void org.kde.KApplication.updateUserTimestamp()
method void org.kde.KApplication.updateUserTimestamp(int time)
property readwrite int com.trolltech.Qt.QApplication.cursorFlashTime
property readwrite int com.trolltech.Qt.QApplication.doubleClickInterval
property readwrite int com.trolltech.Qt.QApplication.keyboardInputInterval
property readwrite bool com.trolltech.Qt.QApplication.quitOnLastWindowClosed
property readwrite int com.trolltech.Qt.QApplication.startDragDistance
property readwrite int com.trolltech.Qt.QApplication.startDragTime
property readwrite int com.trolltech.Qt.QApplication.wheelScrollLines
property readwrite QString com.trolltech.Qt.QCoreApplication.applicationName
property readwrite QString com.trolltech.Qt.QCoreApplication.organizationDomain
property readwrite QString com.trolltech.Qt.QCoreApplication.organizationName
method QString org.freedesktop.DBus.Introspectable.Introspect()
method QVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QVariant value)

One interesting thing you may note is that, if your application is a KUniqueApplication, you automatically get a org.kde.KUniqueApplication.newInstance method.

And when you're done with your test, you can just quit it:

$ dbus local.kmainwindowtest /MainApplication quit

[1]+  Done                    ./kmainwindowtest
$

With commit 546830, KDE says good-bye to one of its longest friends: DCOP. The technology has served us well for 6 years, to the point that has become one of our most proeminent features. Many KDE applications are given an edge over their competitors by supporting advanced functionality through DCOP: you can tell a Konqueror page to evaluate a JavaScript code snippet (think document.write...), tell a Kate window to raise itself, Kontact to check email or Kopete to send an automated message, etc.

We now say hello to DCOP's younger brother: D-BUS. I merged this morning all the changes I had in a separate branch back into trunk. This completes one phase of the work and starts a new one!

D-BUS brings us better interoperability with many other programs. While DCOP was pretty much restricted to KDE applications (yes, I know there were C bindings, but not many people used it...), D-BUS already comes with bindings for several other major frameworks: glib, Java, Python, Perl, Mono, etc. D-BUS has been designed from the ground up to be an interoperable IPC system and also to replace DCOP when the time came. And so it did.

D-BUS also allows us to better talk to our own system: projects like HAL and Avahi are already being used by many Linux distributions to let normal applications get access to some privileged resources. In time, I also hope the Portland Project to come around and use D-BUS for its IPC needs, thus freeing us from using a special library with its own protocol to do what D-BUS already does.

You may have noticed a pattern in the links above: all are "freedesktop.org". So, yes, KDE is collaborating with the free desktop initiative. But D-BUS isn't restricted to freedesktop.org projects! In case you didn't know, the Nokia 770s use D-BUS extensively for its own internal IPC. There's also the Tapioca Project using D-BUS. Those are just a few: there are many more (and that list is far from complete).

And, of course, KDE now. (We probably bring more applications into D-BUS in one go than there currently are...)

Many thanks to Simon Hausmann, Harald Fernengel, Kévin Ottens, Benjamin Meyer and Roberto Raggi for helping me with the KDE Libs port to D-BUS. And many thanks to Trolltech for letting me develop and maintain the QtDBus bindings.

So after a few weekends of work (and some not working), some friends and I have finally finished porting kdelibs from DCOP to D-BUS. It compiles, links and installs. I've just made the final commit on Subversion (I had forgotten to remove a few files from installation).

I'd like to thank Harald Fernengel, Simon Hausmann, Ben Meyer, Roberto Raggi (thanks for the Tiramisu!) and Kévin Ottens for the help on porting. At least if I drop off the face of the earth tomorrow, there's someone with knowledge

You're going to ask: was it difficult? What was the trickiest code?

Well, I'd have to say that the most tricky things in DCOP to port are hand-written code, especially hand-written signals. KDELibs had a lot of hand-written DCOP calls and even a few hand-written DCOP objects. In other words: they marshalled and de-marshalled the arguments themselves, which means a lot of code to be ported.

The problem with signals is that the low-level DCOP (i.e., not using generated skeletons and stubs) has no concept of signals. It only has broadcast calls. On the other hand, D-BUS has no such thing as broadcast calls: it only has signals. So I've had to convert those broadcast calls into proper signals. Sometimes, the code ended up being very ugly because of that.

I'll start taking a look at how to port kdebase now. If you want help, I've put a simple HOWTO in the wiki.

With less than 2 hours to go to submit applications, students must be busy smoothing the final edges of their texts before submitting to Google. And as it turns out, we're getting some very interesting ideas for Summer of Code this year. I hope the quality of the proposals is indicative of the quality of the code we'll see in the next three months.

But I already do have one complaint:

Why did you all wait so long to submit?!

Last week, I was really worried when we had a handful of applications only. I was worried we had not done our job getting the information out before the deadlines. Compared to last year, we received a lot less applications. In fact, by the end of the second day, we had more mentors available than applications to mentor.

But now, in retrospect, I think I can come up with at least a few good reasons why that happened:

1. Those are students! They have classes!
2. We had more than one week last year and I only joined the mentors well into the second week
3. We also had a lot more spam and completely clueless users last year (people who just copied & pasted our short ideas)

I'd also like to thank all the mentors and all the students participating. And I'd like to say that the KDE community welcomes all new contributors, so, even if you don't get selected, please consider trying out your idea anyways.