EfficientCodingStrategySpec

Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2006-11-11 17:16:26
Size: 2890
Editor: u-121-071
Comment:
Revision 6 as of 2006-11-11 17:32:17
Size: 3053
Editor: u-121-071
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
##(see the SpecSpec for an explanation)

''Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.''

## Register at https://launchpad.net/distros/ubuntu/+specs
## page was renamed from EffectiveCodingStrategySpec
## page was renamed from EffectiveCodingSpec
Line 10: Line 7:
Design applications in a manner to share code between different desktop environments. 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.
Line 15: Line 16:
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. 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.
Line 17: Line 18:
A good example for illustration 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. '''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.
Line 19: Line 20:
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. 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'''.
Line 21: Line 22:
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. 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.
Line 23: Line 24:
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. 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.
Line 25: Line 26:
Consequently, we should ensure in the future, that this does not happen again. Common grounds must be found, universal tools created, efforts shared. Consequently, we should ensure in the future, that this does not happen again. '''Common grounds must be found''', universal tools created, efforts shared.
Line 29: Line 30:
Wasn't this the idea of Open Source anyway? '''Wasn't this the idea of Open Source anyway?'''
Line 33: Line 34:
* Power Management
* Laptop Buttons

Both could be handled by a daemon and controled by an individual GUI in each desktop environment. Other candidates could certainly be identified.
  * Power Management
  * Laptop Buttons
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.
Line 53: Line 53:
CategorySpec CategorySpec CategorySpec

Summary

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.

Rationale

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):

  • Power Management
  • Laptop Buttons

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.

Scope

Design

Implementation

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion


CategorySpec

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