This is more a general strategy than a specification for a specific application. The suggested strategy is:

Design applications in a manner to share code between different desktop environments.

Most promising approach: Common daemons working in the background communicating with thin GUI clients in the desktop environments.


I understand Ubuntu as a project where people of different interests and origin build their dreams together on common ground. We have come far but it is still far to go until we can really say, we live/develop following the concept mentioned above.

At the current time I still see talent, time and energy wasted by Ubuntu family members of different religion each one trying to reinvent it's own wheel. Instead they should create one stable felly together and apply their unique touch to it by adding their custom hub cap.

A good example to illustrate this is network-manager. The deamon running in the background represents the felly, the common ground. And the Gnome and KDE GUIs represent the individual hub caps.

This approach ensures there are not two incompatible implementations for the same problem in Ubuntu like powernowd and kpowersaved. And work is not lost, like all the KDE attempts to create a config utility for wlan devices. Or even like with dcop which will be replaced by dbus in KDE4.

Possibly dcop could be what dbus is nowadays, if only this technology would not have been hidden inside kdelibs, unaccessible for anybody interested, only to be available when installing kdelibs and even the QT library which it depends on.

For that reason huge coding efforts are lost for ever, programming hours wasted, because of course it does not make sense for KDE to maintain dcop if dbus is around anyway and fulfils the same purpose.

Consequently, we should ensure in the future, that this does not happen again. Common grounds must be found, universal tools created, efforts shared.

Great things could be acieved if Ubuntu when all it's flavours act like a big family. The efforts of the one family member should also be beneficial for the other members as well.

Wasn't this the idea of Open Source anyway?

Use cases

The next best candidates for applying this strategy would be (add your suggestions):

Both of the above could be handled by a daemon and controled by an individual GUI in each desktop environment. Other candidates could certainly be identified.





Data preservation and migration

Unresolved issues

BoF agenda and discussion


EfficientCodingStrategySpec (last edited 2008-08-06 16:38:59 by localhost)