JAN
1
2008

Plotting my revenge...

Okay so I can say 2007 sucked the big one, but 2008 is looking good so far.

2006-2007 had been a pretty rough time for me. In 2006 I set aside my consulting company and my wife left me. It was a little too much drama and change for me. 2007 was pretty much set dealing with the crap that followed all the changes of 2006. I would like to apologize to everyone for letting KDE Developers fall by the wayside at that time. Special thanks for jriddell and beineri for picking up the slack there.

So now here we are 2008 and I'm ready to get back into OSS development again. I regret missing the difficult part of KDE 4, but alas, I am sure there is more than enough work to be done yet on the project. I am curious to see how QtScript is going to impact KDE, and well dbus so far has been an utter disappointment from my POV. I think if one doesn't exist, I will need to port the dcop command line tool to dbus since the dbus command line tool is well disappointing.

I have been working on my own project Flo during my pause. Sad when coding is your lifeline, but its been a place I can experiment with Qt 4.x technology. Its a mind mapping tool, but its largely incomplete.

Other than that I have been increasingly obsessed with concepts behind the wiki and how to build that more into a desktop. I have also because of my curious employment become very interested in ways to make KDE more thinclient friendly. Making a remote desktop is easy... now lets get remote filesystems, usb, and audio :)

So what will 2008 bring? Who knows, but it cant be any worse than the last two years! First thing is first though. I need to do a svn checkout and build asap :)

Comments

Welcome back!

Could you expand a bit on why dbus is a disappointment (assume more than just having a dbus commandline tool)? Perhaps compare it to dcop if certain things have been lost?


By bkor at Tue, 01/01/2008 - 17:11

I am also really having serious problems with this send a message based cruft. Not shockingly I dislike SOAP for the same reasons. In my limited opinion DBUS seems to have made all the same sins. Why they couldn't take more of a lead from xmlrpc is a question only the implementers can say.

My problem is I really fell in love with the idea of invoking a remote method, vs sending a message to an object floating in space. Its also VERY unclear how the custom Qt types will play with the rest of the world. I get the impression there is a way to add a custom serializer for QVariants, but I have not had a chance to dig into it.

Really its a matter of taste, and I am sure with a minimal amount of effort, I can either change the flavor, or change my preference.


By Ian Reinhart Geiser at Tue, 01/01/2008 - 17:22

My problem is I really fell in love with the idea of invoking a remote method, vs sending a message to an object floating in space.

I consider this to be more a matter of terminology, a method call is also often referred to as sending a message to an object.

Sure, the method call is transported as a message on the D-Bus, but from the point of view of both caller and callee it is just a remote method invocation.

However, the currently available D-Bus commandline tools might not be as good as they could be, i.e. qdbus is usually more convenient but sometimes one needs to use dbus-send instead (e.g. when a remote object does not support introspection)


By krake at Wed, 01/02/2008 - 08:33

I fully agree about the d-bus stuff. The command line stuff is not all comparable with DCOP. With DCOP we could easily script a KDE application from the outside. With d-bus this should also be possible, but the command line tooling isn't as friendly as the old d-bus friend. kdbus is also not very user friendly.

This doesn't mean however that I don't like the technology, I do. But user space tooling isn't as friendly as back in the DCOP days.


By dirtyharry at Tue, 01/01/2008 - 17:59

Same sentiment as parent post. I understand dcop (the command-line tool). I have no idea how to do the same things with D-Bus. If you can make D-Bus easy to use (like, "dbus Amarok player play") that would be wonderful. 'Cause I can't figure this D-Bus thing out. (Maybe I'd have better luck if kdbus wouldn't freeze whenever I try to run it.)


By kwilliam at Tue, 01/01/2008 - 20:45

qdbus org.kde.amarok /Player play

(assuming the Amarok developers put their old "player" object under the new "/Player" object path).

What's so hard about qdbus?


By Thiago Macieira at Thu, 01/03/2008 - 20:33

I'm really sorry to hear the last two years were so rough for you.
The wiki idea reminds me of an application Matthias Ettrich was working for a while about 2 years back which basically was wiki-like editor for desktops. Expanding that with a short per-file history builtin into KIO that all KDE apps could access would be pretty awesome.
You always had some of the most creative ideas for KDE. It's great to have you back :)


By zack rusin at Tue, 01/01/2008 - 20:48

Man, +10 for that idea. I can see it somewhat nicely playing with database mappings that replace/compete with tranditional hierarchical storage.

I am also looking forward to see Ian's development.


By Jarosław Staniek at Tue, 01/01/2008 - 23:08

Welcome back, Ian!

You've been missed. I'm very glad that you're back and I'm sure there are plenty of others who are too.

If you want to talk about D-Bus, how to improve it, etc., talk to me any time (IRC, email, IM, etc.). I hope to do some work there on Qt 4.5 and improving the command-line and GUI tools is in my goal list.


By Thiago Macieira at Thu, 01/03/2008 - 20:36

I hope things will be better this year for you ...
glad to see you're still alive


By Mathieu Chouinard at Thu, 01/03/2008 - 20:52