There is an article over at linux.com which predicts that the Portland initiative will fail to reach its goal of "unifying the Linux desktop".

Unfortunately the author somehow missed that "unifying the Linux desktop" is not the goal of Portland.

While I have been a KDE developer for ages, this will be my first KDE conference and I am even one of the few lucky ones that had their talk proposal excepted :)

Btw, talking about luck: has anyone else not yet received confirmation about their hostel reservation/payment?

Anyway, since I am currently not directly working on any KDE core parts, I am pondering what I will be hacking on during the coding marathon.

If the title doesn't tell you anything, you'll be a lot wiser after reading this :)

So I bought this new Vaio laptop.After checking that the really nice Vaio recovery tool does indeed leave any main operating system intact when restoring the pre-installed entertainment system, I was about to install the usual Debian/SID onto it.

Yesterday I got my new laptop. I got it in the meanest possible way I could have imagined: two minutes before I had to leave for work
sigh

I barely had time to check the contents of the box and it didn't matter what kind of things I got to work on at the office, most of my thoughts were occupied with my precious.

It's a VAIO SZ1XP, according to the reviews a subnotebook, but its keyboard feels huge compared to my current laptop, a HP Omnibook 6100 (15" model).

Once upon a time, I believed in fairy tales.

Later, during my software engineering education, I came across a fairy tale called "capabilties detection".

... and Aaron blogs about an entry in Murray Cumming's blog, I feel entitled to reply using my own :)

Murray fears that from his point of view suboptimal choice will negatively impact the whole free desktop market and while his wording could be intentionally unpleasant about KDE, I guess that he actually believes it.

Beside being a developer I consider myself part of the KDE support team.

I have been doing developer and end user support for a couple of years now, for the last two years almost exlusively (read no development).

Bram has issued a reminder that KDE has a web forum for user support, asking other KDE constributors to come over and help.

Lubos woke the dormant Portland project by creating a first implementation of a possible desktop adapter API.

Having some experience due to my work on QDS I volunteered to put some work into it as well, especially KDE related backend code.

...here. Yet.

"Yet" because I don't have anything to commit as all involved code is littered with commented codeblocks of failed attemps.

I am talking about a QObject adapter for the Qt3 D-BUS bindings, i.e. a wrapper class that makes slots of a given QObject instance callable through D-BUS.
Generating D-BUS introspection data from the slot signature is next.

The last few days saw a couple of threads on the dbus mailinglist about topics we KDE users got used to love in DCOP.
For example how to start browsing for interfaces on applications connected to the bus, in D-BUS terminology called introspection, how to know which session busses are currently active for a user and how to work with users session busses from the system bus.

The last two features are known to DCOP commandline client users as

dcop --all-sessions

and