BoFs, BoFs and more BoFs

The nice things when meeting everyone at aKademy is that you can very easily talk face to face to people.

I attended many BoFs including the working group meeting. I liked that everyone was sharing a common goal but it showed that if the group becomes too big making progress is not simple. Funny enough to me this BoF showed the need for structure within the KDE project very much and the intermediate result that a small subgroup shall draft a proposal is showing promise. Mirko did a great job in moderating the discussion.

My personal favourite was of course the RuDI BoF. This group was much smaller and therefore very efficient and easier to do moderation of the discussions.

RuDI got many supporters inkluding Matthias Ettrich who said that he would love to support RuDI for Qt developers. Basically it boils down that Qt developers can keep their current developement model and only need to link to RuDI. This allows all Qt applications to integrate nicely into KDE and default to the native Qt functionality in case RuDI is not available. Qt developers don't need deep KDE knowledge to use RuDI. Matthias should know as Trolltech just recently conducted a [|market research] with feedback from many thousands of ISV which built upon Qt technology. Even though many of these are targeting the Linux desktop they didn't integrate their applications in the desktop at all.

As [|Benjamin Meyer] wrote on the kde-core-devel mailing list reducing the complexity of the current kdelibs and make it easier for non-core developers to use the KDE platform can help us to gain more ISVs, testers and finally more contributors. After all reducing the complexity will be the critical point when recruiting new KDE developers.

Due to the fact that a [|service oriented] approach to the Linux desktop is not limited to KDE but also of big benefit to [|GNOME] we have to think how to best contact the GNOME developers about proposing a common RuDI protocol. IMHO RuDI can also be a suitable technology to integrate [|Mono] applications in both Linux desktop in a clean and robust manner.

I am now wondering whom to approach for this?


It is great that Qt-only applications, and Gnome ones as well as Mono will be able to take advantage of RuDI.

But what about Java? Isn't Java the biggest chunk of the Linux/Unix "GUI-but-non-DesktopEnvironment" market already?

Also: what about Gnome implementing a RuDI spec? Would KDE apps then run better in a Gnome environment, and be able to take advantage of the services the Gnome desktop offers?


By Kurt Pf. at Fri, 09/02/2005 - 17:35

Well, this is exactly the point.

Actually I expect implementations for Qt and Java at first. The reason for this is that Matthias will take care about Qt and most probably I will take care about the Java implementation myself.

Provided that GNOME implements the RuDI spec all RuDI enabled applications including Java and KDE applications will run better in a GNOME environment.

In general the nice thing about using an XML protocol instead of linking is that you don't have any problems with programming languages. The protocol on the wire is purely language independent. I assume that the limited support of DBUS data types is sufficient for our purposes.

By Martin Konold at Fri, 09/02/2005 - 21:16

It sounds like a really cool approach for offering good integration without requiring dependencies on the target platforms.

I think I will try an out-of-process plugin for my QDS project and if it works good enough I might convert the KDE and the newly released GNOME plugin to out-of-process backends.

Would also have the advantage of not depending on a KApplication instance when working with KDE as the running desktop.

By krake at Fri, 09/02/2005 - 18:39

QDS is interesting. Who uses it currently for which purposes?

By Martin Konold at Sat, 09/03/2005 - 17:08

I started working on it after lots of questions about launching default applications on

My first take last year was a little to complicated API wise and I haven't received much feedback about the new version yet.

The one I got so far was about the need for letting QDS create the QApplication instance, which is primarly required for the KDE based plugin (KApplication needed)

I hope to get more feedback soon, especially what kind of services developers would like to have at their disposal (my next idea is to provide methods to setup QActions based on the desktop, i.e. icon, text, accelerators, etc)

By krake at Mon, 09/05/2005 - 05:00

I understand your proposal of RuDI to being a "language-neutral" wire protocol that facilitates the integration of applications. Integration by utilizing of the respective desktop environment's services, and making third-party apps assume/imbibe/embrace the look as well as at least a part of the *feel* of their hosting environment.

Is that correct?

And what about the licensing? Will RuDI also be "license-neutral"? This meaning: will RuDI facilitate cross-integration of services provided by the platforms that implement its specification *regardless* of the licenses that are valid for each of the "partners"?


By Kurt Pf. at Fri, 09/02/2005 - 21:28

The small RuDI lib which will be available for each platform (Qt/Java/KDE/gtk/Mono) shall be available with a no strings attached BSD style license in order to facilitate wide spread use.

As the coupling of a RuDI enabled application with the desktop services does neither create a derivative work nor uses any kind of linking the license used for the desktop services don't affect the RuDI enabled application.

Explicitly it allows for example Adobe to developed Acrobat Reader with gtk+ while integrating nicely in either desktop.

By Martin Konold at Sat, 09/03/2005 - 17:07


I think RuDI is very interesting.
Is there a mailing list or forum available for interested users/potential developers?

By wizeman at Sat, 10/01/2005 - 16:37