For those of you not on the primary devel mailing list, I thought you might like to read the following:<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Elias Humbolt
</b> &lt;<a href="mailto:elias@asb-online.at">elias@asb-online.at</a>&gt;<br>Date: Nov 11, 2006 1:56 PM<br>Subject: Efficient Coding Strategy for Desktop Environment Development<br>To: <a href="mailto:ubuntu-devel@lists.ubuntu.com">
ubuntu-devel@lists.ubuntu.com</a><br><br></span>How more Code could be shared between &quot;competing&quot; Desktops Environments<br>-----------------------------------------------------------------------<br><br>I understand Ubuntu as a project where people of different interests and
<br>origin build their dreams together on common ground. We have come far<br>but it is still far to go until we can really say, we live/develop<br>following the concept mentioned above.<br><br>At the current time I still see talent, time and energy wasted by Ubuntu
<br>family members of different religion each one trying to reinvent it's<br>own wheel. Instead they should create one stable felly together and<br>apply their unique touch to it by adding their custom hub cap.<br><br>A good example for illustration is network-manager. The deamon running
<br>in the background represents the felly, the common ground. And the Gnome<br>and KDE GUIs represent the individual hub caps.<br><br>This approach ensures there are not two incompatible implementations for<br>the same problem in Ubuntu like powernowd and kpowersaved. And work is
<br>not lost, like all the KDE attempts to create a config utility for wlan<br>devices. Or even like with dcop which will be replaced by dbus in KDE4.<br><br>Possibly dcop could be what dbus is nowadays, if only this technology
<br>would not have been hidden inside kdelibs, unaccessible for anybody<br>interested, only to be available when installing kdelibs and even the QT<br>library which it depends on.<br><br>For that reason huge coding efforts are lost for ever, programming hours
<br>wasted, because of course it does not make sense for KDE to maintain<br>dcop if dbus is around anyway and fulfils the same purpose.<br><br>Consequently, we should ensure in the future, that this does not happen<br>again. Common grounds must be found, universal tools created, efforts
<br>shared.<br><br>The next best candidates would be:<br>Power Management and Laptop Buttons<br><br>Both could be handled by a daemon and controled by an individual GUI in<br>each desktop environment. Other candidates could certainly be
<br>identified.<br><br>Great things could be acieved if Ubuntu when all it's flavours act like<br>a big family. The efforts of the one family member should also be<br>beneficial for the other members as well.<br><br>Wasn't this the idea of Open Source anyway?
<br><br><a href="https://features.launchpad.net/distros/ubuntu/+spec/efficient-coding-strategy">https://features.launchpad.net/distros/ubuntu/+spec/efficient-coding-strategy</a><br><a href="https://wiki.ubuntu.com/EfficientCodingStrategySpec">
https://wiki.ubuntu.com/EfficientCodingStrategySpec</a><br><br>Elias<br><br><br>--<br>ubuntu-devel mailing list<br><a href="mailto:ubuntu-devel@lists.ubuntu.com">ubuntu-devel@lists.ubuntu.com</a><br><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel">
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br><br clear="all"><br>-- <br><br><br>Firefox (<a href="http://www.getfirefox.com">www.getfirefox.com</a>) -- A browser you can trust