à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes.
entièrement d'accord. À mon avis, ils ont fait une grosse erreur là. Y'a plein de gens qui aimerait développer des trucs bonobo mais qui ne comprennent pas trop les techniques. Y'a 2-3 tutoriaux de quelques lignes qui traînent mais en pratique ça ne sert pas beaucoup.
Corba a coûté très cher a Gnome en temps de développement et en complexité,
bof, toute la couche CORBA est cachée dans bonobo, la complexité sous-jacente n'apparaît pas quand on programme une appli bonobo.
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.
humpf, je sais pas trop : rien ne t'empêche de définir des méthodes CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.
La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.
A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que tu peux avoir le composant dans un processus séparé.
c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome
mouais. supérieures ? tu nous dis "Bonobo, c'est compliqué et y'a pas de docs, kparts c'est plus simple. Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop". De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
# Re: Gnome Office et KOffice
Posté par Vivi . En réponse au journal Gnome Office et KOffice. Évalué à 4.
à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes.
entièrement d'accord. À mon avis, ils ont fait une grosse erreur là. Y'a plein de gens qui aimerait développer des trucs bonobo mais qui ne comprennent pas trop les techniques. Y'a 2-3 tutoriaux de quelques lignes qui traînent mais en pratique ça ne sert pas beaucoup.
Corba a coûté très cher a Gnome en temps de développement et en complexité,
bof, toute la couche CORBA est cachée dans bonobo, la complexité sous-jacente n'apparaît pas quand on programme une appli bonobo.
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.
humpf, je sais pas trop : rien ne t'empêche de définir des méthodes CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.
La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.
A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que tu peux avoir le composant dans un processus séparé.
c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome
mouais. supérieures ? tu nous dis "Bonobo, c'est compliqué et y'a pas de docs, kparts c'est plus simple. Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop". De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.