> > 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
Oui, mais cacher cette complexite a pris beaucoup de temps, et c'est pour ca que bonobo est aussi peu developpe a l'heure actuelle.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Tant que t'as pas d'exemple concret, ca veut rien dire. Perso, j'ai apprecie de pouvoir comprendre comment fonctionnait kpart en lisant du code pendant une demi-heure, alors que je ne connaissais rien a KPart et aux bibliotheques partagees.
> 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.
Moui, mais tout de suite, c'est plus complique. Avec un kpart, une fois que tu as remplace ton pointeur MyApplicationWidget par MyApplicationKPart, toutes les methodes a appeler restent les memes donc n'as pas plus de code a changer.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Ce n'est qu'un a priori, qui s'est revele faux dans la pratique. Le fait d'avoir un processus separe fait que tu as peu de controle quand qqch plante, et il reste des processus qui tournent en arriere plan, parfois sans que tu t'en rendes compte.
Avec un kpart (dixit David Faure, qui a bosse a la fois sur la partie Corba de KDE a l'epoque ou KDE faisait du corba et sur la parti KPart), c'est beaucoup plus franc. Ca plante, tu le vois tout de suite et tu as un core pour debugger.
Debugger un kpart est egalement plus simple parce que, quand tout est dans le meme processus, tu peux poser un breakpoint et faire tourner ton debuggeur sans souci. Avec plusieurs processus, il te faut pas mal de debuggage en parallele, pas forcement facile a mettre en place: un pour le serveur corba, un pour le composant, un pour l'hote du composant. Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.
> Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop".
De fait. Et certaines manquent pour le desktop. Combien de temps faut-il pour lancer un processus et pour charger une bibliotheque partagee a ton avis ? Qu'en est-il de l'occupation memoire ? Et je me repete mais le fait que l'api soit plus complexe a utiliser est penible.
> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops. Superieur dans l'absolu ne veut rien dire. Superieur dans le cadre d'une utilisation en desktop oui.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. Évalué à 1.
> > 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
Oui, mais cacher cette complexite a pris beaucoup de temps, et c'est pour ca que bonobo est aussi peu developpe a l'heure actuelle.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Tant que t'as pas d'exemple concret, ca veut rien dire. Perso, j'ai apprecie de pouvoir comprendre comment fonctionnait kpart en lisant du code pendant une demi-heure, alors que je ne connaissais rien a KPart et aux bibliotheques partagees.
> 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.
Moui, mais tout de suite, c'est plus complique. Avec un kpart, une fois que tu as remplace ton pointeur MyApplicationWidget par MyApplicationKPart, toutes les methodes a appeler restent les memes donc n'as pas plus de code a changer.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Ce n'est qu'un a priori, qui s'est revele faux dans la pratique. Le fait d'avoir un processus separe fait que tu as peu de controle quand qqch plante, et il reste des processus qui tournent en arriere plan, parfois sans que tu t'en rendes compte.
Avec un kpart (dixit David Faure, qui a bosse a la fois sur la partie Corba de KDE a l'epoque ou KDE faisait du corba et sur la parti KPart), c'est beaucoup plus franc. Ca plante, tu le vois tout de suite et tu as un core pour debugger.
Debugger un kpart est egalement plus simple parce que, quand tout est dans le meme processus, tu peux poser un breakpoint et faire tourner ton debuggeur sans souci. Avec plusieurs processus, il te faut pas mal de debuggage en parallele, pas forcement facile a mettre en place: un pour le serveur corba, un pour le composant, un pour l'hote du composant. Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.
> Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop".
De fait. Et certaines manquent pour le desktop. Combien de temps faut-il pour lancer un processus et pour charger une bibliotheque partagee a ton avis ? Qu'en est-il de l'occupation memoire ? Et je me repete mais le fait que l'api soit plus complexe a utiliser est penible.
> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops. Superieur dans l'absolu ne veut rien dire. Superieur dans le cadre d'une utilisation en desktop oui.