Ca m'a pris trop de temps a tapé, c'est dommage de l'enterrer au fond d'une thread sur linuxfr. Donc voici ma réponse à la thread:
http://linuxfr.org/2003/09/17/13961.html(...)

-----------------------------------------------------------------------

> Gnome assure une communication (et de qualité). Trop peu d'applications Gnome l'utilisent.

T'es tu demandé pourquoi ? Il y a une raison. C'est que mettre un composant bonobo en place, c'est pas aussi simple et léger que mettre un kpart en place. Dans ma vision personelle, je pousserai même jusqu'à dire que programmer une application en gtk/gnome demande un investissement significatif en temps, et que des lors, il ne reste plus beaucoup de temps au programmeur pour faire des petits trucs en plus. Ces petits trucs pouvant être de respecter correctement les HIG ou rendre son application disponible sous forme de composant. Mais laissons cet aspect controversé de côté et regardons des éléments objectifs.

Je pense que le succès plus important des composants dans KDE est lié aux points suivants:
- kpart existe depuis plusieurs années dans KDE
- c'est bien documenté et très léger à mettre en place pour un développeur
quelques références:
http://phil.freehackers.org/kde/kpart-techno/kpart-techno.html(...(...))
http://developer.kde.org/documentation/library/3.1-api/kparts/html/(...))
http://developer.kde.org/documentation/tutorials/index.html(...(...))

à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes. J'en avais cherchées il y a deux ans et un an et je n'avais presque rien trouvé. Depuis Michael Meeks a pondu quelques bonnes documentations.

- bonobo n'est arrivé à maturité que récemment
- très peu d'applications sont bonobo-aware.
- comme beaucoup d'applications utilisent déja des kpart, il est facile de trouver des exemples sous KDE. L'effet inverse joue sur Gnome

Donc en gros, il semble que la différence provienne de la maturité tardive de bonobo. Comment se fait-il que bonobo arrive à maturité aussi tard alors même que les composants faisaient partie de la vision de base d'un bureau développé par MDI (cf sa page web, vision très intéressante et qu'on peut voir réalisée aujourd'hui ... dans KDE!). Au départ, Gnome n'a qu'un an de retard sur KDE mais en terme de composants, on est a peine dans Gnome au niveau qu'on avait dans KDE 2.0

Je suis intimement persuadé que la raison de ceci est que les technologies KDE pourtant très largement critiquée en leur temps sont bien plus adaptées au problème. Le fait du partir sur du Corba a coûté très cher a Gnome en temps de développement et un complexité, pour un résultat qui n'apporte rien de plus que kpart, ou bien des choses qui ne servent à rien. Par exemple, j'aime bien cette phrase dans le tutorial de bonobo: "Finally, using a component model allows the running of your controls on other machines. There must be someone, somewhere who wants that."

D'un point de vue développeur, ce que je vois comme inconvénient à bonobo:
- peu d'applications l'utilise donc c'est dur de trouver des exemples
- l'échange d'informations par property bag est lourd à mettre en place.. Cela veut dire que le développeur Gnome doit modifier pas mal son code pour gérer la communication avec le composant bonobo. KPart de son côté remplace un appel de méthode par un appel de méthode. Et dehors du type des pointeurs qui change, migrer du code vers kpart est très rapide
- s'il y a un probleme avec bonobo, il faut descendre dans les couches basses et ça devient tout de suite très compliqué: c'est du corba. La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.

> Je n'ai jamais vu une KPart s'écrire toute seule.

Il faut moins de 50 lignes de code pour passer une application en KPart. C'est vraiment proche du "ça s'ecrit tout seul"


> rien de tel n'existe sous Gnome Office et donc le mot integration est tres tres exagere.
> Probablement exact, mais je ne vois pas en quoi ça rend KDE meilleur (juste KOffice).

Le point important, c'est que les technologies KDE sont plus avancées et permettent de faire ce genre de chose beaucoup plus facilement. Et, c'est grâce aux technologies mises très tôt en place dans KDE, sur lesquelles KOffice ne fait que s'appuyer.

> Vous n'avez pas montré que KDE était supérieur à Gnome, juste que KOffice est meilleur que Gnome Office pour certaines raisons

Ce que je veux montrer, ce n'est pas que KOffice est supérieur à Gnome Office, c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome.

On a parlé composant mais si on parle de scriptabilité, Gnome est carrément à des années lumières de retard.

Imaginons par exemple que je veux ouvrir une konsole avec trois sessions ssh vers trois différentes machines avec un script:

# launch konsole with remote dcop control enabled
konsole --script &
# process-id is used to generate the dcop name of konsole
kid=konsole-$!
echo Konsole is $kid
session="session-1"
# you need to add a small delay
sleep 0.5

dcop $kid $session sendSession "ssh machine1"
sleep 0.5

# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine2"
sleep 0.5

# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine3"

J'aimerai voir la version équivalente de ce script pour Gnome. Notons que ce genre de chose est possible depuis KDE 2.0 . Pour en savoir plus:

http://developer.kde.org/documentation/tutorials/automation/index.h(...))



> Cette affirmation serait-elle donc un troll grossier ?

Non, c'est une opinion que je suis en mesure d'argumenter.

> Lire le journal (56 commentaires, moyenne: 1,5).