> Et c'est toujours à toi de coder le slot si ce n'est pas un slot prédéfini.
Oui, mais beaucoup de slots predefinis sont suffisants. Typiqueemnt, pour un dialogue de configuration ou certains checkbox et combo vont activer ou desactiver d'autres widgets, tu peux faire tout avec Qt Designer puisque tu vas utiliser des signaux et des slots existants. Je trouve ca plus fun que de le faire dans le code.
> > Glade ne permet que de reagir en terme d'evenements (j'ai clique ici, appelle moi cette fonction)
> Si. Faut regarder dans les propriétés de l'object.
J'ai pas vu ou pas compris comment il fallait faire. On peut choisir de connecter un signal a un callback, mais pas un signal a callback d'un autre objet. Ou en tout cas, j'ai pas compris comment il fallait faire. Je voudrai faire l'exemple plus haut, ou un combo-box met a jour un champ textedit. A la rigueur, si tu peux le faire, envoie-le moi par mail, ca m'interesse.
Pour l'absence des widgets Gnome, c'est parce que ma gentoo a pris mon setting par defaut qui est sans gnome.
> J'ai cree un combo-box mais je ne peux pas le remplire.
Correction, je peux remplire la combo-box. Le lien "Edit Menu" n'est pas tres parlant. En revanche, je n'ai pas pu remplire la GtkTreeView
Donc une impression moins negative que la premiere fois mais quand meme, c'est pas encore ca.
> Pour les "processus en background" c'est plus ou moins faux. Pour evolution (et d'autres) il n'y a pas de processus en backgroup.
> Les composans sont chargés par le programme comme une librairie.
Juste pour rire, combien d'annees-hommes depensees dans Bonobo pour lui faire faire au final la meme chose que dlopen ? Au moins une et demi, celle de Michael Meeks. A mon avis, c'est beaucoup plus. Donc en fait, on super-corba et super-bonobo mais on fait la meme chose que dlopen. Trop fort!
> Es-ce que les utilisateurs trouvent KDE plus rapide ou plus léger que Gnome ?
Oui.
Mais les utilisateurs de Gnome trouvent aussi Gnome plus rapide que KDE. Donc tout ca est tres subjectif. Et a part des arguments subjectifs, je ne t'ai pas vu contribuer grand chose a cette conversation, si ce n'est ton soutien presque inconditionnel a Gnome.
> et comment je fais avec du OCaml normal, ou du python normal, ou du perl normal, etc. ?
C'est vrai que cet aspect est un peu plus difficile a avoir. Mais peux-tu me citer des composant bonobo OCaml, python et perl ? Ben y en pas, c'est plutot rare comme besoin.
Pour faire des composants dans un autre langage, c'est un poil plus dur puisqu'il faut commencer par faire une espece de chargeur de composant dans le nouveau langage en kpart et ensuite faire des composants pour ce chargeur. C'est deja fait pour le python, ce sera fait pour les autres langages quand les gens en auront besoin. Pour l'instant, le besoin n'est pas tres present.
> Oui mais là tu n'as plus de communication entre tes machins, il faut mettre en place de l'IPC séparément.
Le plus simple est de choisir DCOP. Soit tu utilises la lib existante (binding presents en C, C++, bash, python, perl, ruby, java), soit tu te refais le marshalling dcop qui est documente.
Meme comme ca, je pense que c'est moins lourd que Bonobo a utiliser
Tout a fait. Quand je vois le support developpeur qu'ils ont, ca fait peur. Ils ont ou ont eu dans leur histoire plusieurs equipes travaillant a plein temps sur Gnome (Ximian, Redhat, Eazel, wipro, Sun, ... ) et le resultat est a peu pres au niveau de KDE.
A cote, KDE reussi a sortir un navigateur, un IDE, une suite de communication integree, une suite office. Et pourtant, il y a une demi-personne payee sur konqueror (maintenant, c'est 0 personnes payees), une demi personne payee sur KOffice (avant, c'etait une personne), une personne payee sur toutes la partie config/backend et une autre personne payee pour faire ce qu'elle veut.
C'est marrant, KDE au contraire a fait le choix d'utiliser des petits fichiers independants, par application, dans la plus pure philosophie unix. Va voir dans $KDEDIR/share/config pour configurer tout ce que tu veux pour le systeme et dans ~/.kde/share/config pour tes config perso.
Et on dit que c'est KDE qui ressemble a Windows...
Tout a fait. Et ce nettoyage est rendu particulierement difficile a cause de la structure de la base de registre ou n'importe quel programme peut mettrre 300 entrees a 50 endroits differents sans te le dire.
Si Microsoft avait un truc propre ou chaque programme avait une zone reservee en dehors de laquelle il n'a pas a ecrire, on aurait moins de probleme.
Tu vas me dire que c'est ce qu'a fait Microsoft mais que c'est le vilains programmes qui font pas ce qu'il faut. Mais bon, je ne prends pas. Si Microsoft avait bien fait son boulot, les problemes de base de registre aujourd'hui, on n'en aurait pas.
On se demande bien qui a pu leur donner cette idée. T'as pas l'impression que le rôle de la jeune vierge effarouchée <<mais qui a pu leur laisser penser qu'il fallait rebooter, je ne comprends pas ? >> n'est pas du tout crédible ?
70% des logiciels sous windows te demandent de rebooter après une installe. Sous les anciennes versions de windows, tu rebootais pour un oui ou pour un non (je change mon adresse IP, je reboote).
Moi c'est pour windows, je lui fous regulierement mon poing dans son moniteur. J'applique avec joie l'adage:
"Bat souvent ton windows car si tu ne sais pas pourquoi tu le bats, lui, il le sait".
Pas mal. Si je comprends bien, ca marche parce que le papier peint est une option de configuration qu'il suffit de modifier.
Qu'en est-il si tu veux agir sur un objet qui n'est pas une option ? L'autre jour par exemple, j'ai ecrit un script bash + dcop pour recuperer les URLs de tous les onglets ouverts dans konqueror. Je m'en suis servi aussi pour envoyer des commandes dans plusieurs onglets d'une konsole via un script bash. Pour ce genre d'utilisation avancee, je ne pense pas que gconftool suffise.
> Maintenant je connais, et Qt Designer n'est pas meilleur que Glade.
Je viens d'utiliser glade (version 2.0) pour voir et il manque pas mal de chose pour en faire un outil aussi bon que Qt Designer.
Comment je fais pour connecter un signal a un slot ? Glade ne permet que de reagir en terme d'evenements (j'ai clique ici, appelle moi cette fonction), facon visual basic mais il ne permet pas de faire plus.
En une minute de Qt Designer, tu peux faire un combo-box qui met a jour un champ edit en fonction de l'item selectionne dans la combo (connecter le signal activated(QString) du combo au slot setText( QString) du texteedit) mais faire la meme chose sous glade ne me semble pas possible. L'exemple combo est relativement simple, en general, j'utilise Qt Designer pour faire des trucs quand meme plus complexes, avec des combo qui invalident les widgets, des check box qui cachent des widgets. Tout ca doit se faire cote code avec glade.
Il ne m'a pas semble voir les widgets specifiques Gnome. On ne peut faire que du Gtk avec glade ?
J'ai cree un combo-box mais je ne peux pas le remplire. Idem pour un GtkTreeView, impossible d'ajouter des elements dedans. J'en conclus qu'on ne peut avoir que des widgets vides. Plutot decevant.
Comment je fais pour choisir l'ordre de la navigation clavier avec tab ?
Pour ce qui est de l'aide, l'onglet Help de glade ne contient que un miserable dialgue 'about glade'. Quid d'un tutorial ou d'un document d'aide ? C'est d'autant plus dommage que le systeme de gestion de l'aide est vraiment tres bien fait sous Gnome et je trouve l'afficheur plus joli et plus fonctionnel que celui de KDE. Le site web est lui-meme tout aussi pauvre en documentation.
En resume, je comprends que tu n'aies pas vu de grande difference entre glade et Qt Designer si tu passes du premier au second mais dans l'autre sens, la transition est difficile.
Objevctive C etait clairement le futur avec la bonne facon de faire. Ca n'a jamais pris cote langage. Je pense qu'il etait trop different du C et que ca a rebute les gens. La force de Java et de C#, c'est que un developpeur C ou C++ s'adapte tres tres facilement. Objective-C, justement parce qu'il gere les objets de la bonne facon est plus dur a apprehender et on passe par du rmi ou du dcop pour faire ce qui aurai pu se faire si naturellement.
Corba, c'est bien mais ca ne correspondait pas aux besoins. Donc il ont depense un travail enorme pour que bonobo soit aussi simple que kpart a utiliser. La gestion des exceptions en C est une veritable horreur, t'as 10 lignes de gestion d'erreur a chaque ligne qui appelle du Corba.
C'est sur que pour des familiers de Corba comme toi, c'est decevant. Mais vraiment, le besoin en question n'est pas Corba.
Pour ce qui est de la distribution de gconf en reseau, c'est en effet une problematique interessante. Mais il suffit de modifier un tout petit peu gconf pour le faire, pas besoin de faire rentrer corba dans toutes les applications.
Sinon, DCOP ne signifie pas en effet que Corba est exclu, c'est juste que c'est pas le mecanisme par defaut. Il serait tres facile en effet de generer des composants Corba a partir des informations fournies par DCOP. Personne ne l'a fait jusqu'a present, probablement parce que personne n'en a besoin.
Dans le meme ordre d'idee, il serait relativement facile de faire un pont bonobo - kpart. Mais personne n'en a besoin.
Je pense que Corba est vraiment un super truc, mais qu'il est completement inadapte a la problematique des composants graphiques.
La force de Corba, c'est:
- composant independant de la plate-forme
- composant independant du langage
- distribution des composants sur plusieurs machines
Ces avantages ont evidemment un cout:
- toutes les communications entre composant se font par un IDL et via le reseau. Declarer les interfaces est assez lourd
- parce que les composants sont reclames a un serveur, ca prend pas mal de temps d'activer un composant
- l'ensemble du framework est relativement lourd a apprendre, a installer et a gerer
- la consommation memoire du tout n'est pas forcement negligeable. Le marshalling et la communication reseau introduisent des delais
- le debug de tout ca est une horreur. Quand le serveur tombe, il te reste plein de processus en background a tuer.
Apres une reflexion de fond, il apparait que les besoins en terme de communication pour un bureau comme KDE sont:
- pouvoir notifier toutes les applications d'un evenment facilement (ejection du lecteur CD, nouveau mail, application lancee, ...)
- d'etablir des canaux de communication entre applications pour echanger des informations relativement simples (ouvre moi cette page web, affiche moi le lien bidule dans la barre d'etat, ...)
- faire des requetes sur les applications : donne moi la liste de tous les composants editeur de texte, dis moi si kmail est deja lance, ...
Tout ca devant s'executer relativement rapidement puisqu'il y a une interaction avec l'utilisateur.
Cote composant graphique, les besoins sont:
- etre capable d'associer un role a un composant et de faire des recherches par role
- charger le composant tres rapidement de facon a ce que l'utilisateur ne voit pas qu'il y a une distinction entre l'application (konqueror) et le composant (khtml).
- avoir une structure globale tres legere pour que ca se charge vite
- le tout doit etre facile a apprendre de facon a ce que les developpeurs qui travaillent sur leur temps libre puisse facilement ecrire des composants.
En regardant ces listes, on voit que les points forts de Corba ne font par partie des besoins, alors que certaines de ses caracteristiques vont poser des problemes. Typiquement, sur un bureau, toutes les applications du bureau sont lancees par le meme utilisateur, sur le meme ordinateur. L'idee d'avoir un konqueror ou le composant khtml serait en train de s'executer sur un autre ordinateur parait un peu incongru. Le besoin de travailler sur plusieurs ordinateurs en meme temps est deja rempli par X ou par vnc.
Donc je ne crache pas sur Corba en general, mais sur cette application de Corba en particulier. Les technos developpes par KDE lorsqu'ils se sont rendu compte de la problematique que je viens d'exposer (c'est pas moi qui l'ai invente, je l'ai lue) repondent parfaitement aux besoins enonces avec rien de trop:
- DCOP est leger et permet de faire tout ce qui est dit
- kpart est leger, ca se charge tres vite puisque c'est une bibliotheque partagee
- pour ce qui est de la communication entre le composant et son applciation, on utilise un simple appel de fonction C++ puisque le composant est charge directement dans l'espace d'adressage de l'application
- pas de marshlling
- hyper simple a utiliser, pas d'IDL, pas de doc speciale a lire, tout marche avec du C++ normal: l'appli doit heriter de kparthost et le composant de kpart.
Et pour les "oui mais si jamais je veux quand meme avoir un composant independant de l'appli qui l'embarque", c'est encore possible. Gtk et Qt implementent tous les deux un mecanisme qui permet d'incruster n'importe quelle fenetre X dans une autre fenetre (XEmbed). C'est ce qu'on utilise pour kvim. Avec ca, on peut lancer un programme quelconque sur une machine distante via le serveur X et l'utiliser comme composant.
C'est en effet l'argument qui a recu le plus de publicité et c'était le problème le plus visible. C'est ce qui a permis au camp Gnome de garder la tête haute en disant que comme orbit serait meilleur, il n'y auraient pas les problèmes de KDE. Ils auraient dû y regarder d'un peu plus pres :
On voit bien que Corba ne répondait pas à la problèmatique pour laquelle on voulait l'utiliser. Un des premiers paragraphes du tutorial de bonobo contient une phrase du type << bonobo peut via corba afficher dans une application un composant graphique executé sur une autre machine et ecrit dans un autre lanage. Il doit y avoir quelqu'un sur terre qui a besoin de cette fonctionnalité >>
Pour moi, ca souligne que l'interet principal de Corba (la distribution de composants sur plusieurs machines) ne trouve pas d'utilité ni dans Gnome, ni dans KDE. Donc pourquoi s'embarasser de Corba ?
J'ai pas dit que c'était nouveau, j'ai dit que c'etait là.
> C'est révolutionnaire
Je ne pense pas non.
> De plus le C ce n'est pas un language de merde
Non. Même, je vais te surprendre mais j'aime bien coder en C. Par contre, coder un Gtk n'a pour moi rien à voir avec du C. Quand je fais des classes, de l'héritage et que je manipule le concept de surcharge de méthode, je préfère utiliser un langage objet où ces paradigmes font partie du langage et ne sont pas rajoutés à coup de bricolage macroesque incertain.
Pour ce qui est de la programmation d'interface graphique, je pense que le C est << un langage de merde >> pour reprendre tes mots. Et ce pour les raisons que je viens d'évoquer.
L'idée de mon post était de rappeler qu'en terme de facilitation de développement d'applications graphiques, KDE a pas mal de mécanismes, la plupart basés sur XML, qui permettent de faire beaucoup de choses de façon automatisée (génération automatique de stub pour dcop) et que au lieu de lorgner en permanence du côté de Microsoft pour de l'innovation, la ximian team ferait bien de regarder de plus pres ce qu'il y a dans KDE et dans les autres projets comme GnuStep.
> Et il a raison sur la proposition d'avoir un language de script central
Malheureusement, ca ne sera pas possible dans la communauté du libre car chacun a son langage de script favori et aucun ne peut vraiment l'emporter. Pour les emacsien, c'est le lisp, RMS recommande le scheme, certains penchent pour python, d'autre ruby, d'autres perl, d'autre Javascript, d'autre C#, lua, Objective Caml, ...
C'est plus facile coté microsoft puisque tout le monde boit ce que dit Bill Gates. A noter quand meme que pendant longtemps, le basic VB etait incompatible avec le basic Access, lui-même incompatible avec sa version précedente, et que tout ca est incompatible avec le basic VB.NET . Bref, faut pas croire que tout est aussi rose que le marketing veut bien le dire. Je me demand même si on n'a pas la vie plus simple, parce qu'au moins, on sait à l'avance que python ne veut pas dire perl.
Ce qui est important, c'est en terme de diversité de langage, c'est que chacun aie accès de la même façon au coeur Gnome ou KDE. La seule facon de garantir cela, c'est de générer automatiquement les bindings comme le font aujourd'hui KDE et Gnome.
> Gnome est toujours là et en pleine forme.
Il est toujours là mais pour moi, il n'est pas en pleine forme. Il a coûté beaucoup plus cher que KDE et terme de mois-hommes. Et quand on regarde les rouages, KDE est beaucoup plus avancé. En trois lignes de bash, je peux m'amuser à faire un fond d'écran dynamique avec mes photos de vacances, sans aucune connaissance précise sur KDE en dehors du fait de taper kdcop.
Un copain qui a fait du Next m'a dit en effet en voyant Qt 1 qu'ils n'avaient fait que reprendre des conccepts déjà présents dans Next. Normal que GnuStep en hérite.
Redhat a un très mauvais historique avec KDE et Qt. On se demande depuis longtemp si ils ne font pas exprès de rendre KDE à moitié inutilisable sur Redhat. C'est triste car une très grosse part d'utilisateurs de KDE est américaine et utilise de fait Redhat.
La situation devrait s'améliorer avec Fedora qui a l'air beaucoup moins fermée que ne l'était Redhat.
> Compare avec la doc, il en manque plein.
Je sais pas si ils y sont tous, j'ai juste dit que aucun ne m'avait manqué. J'ai réussi à faire exactement ce que je voulais sans ressentir de limitation. Lequels t'ont manqué ?
Une différence notable entre Trolltech, Mozilla et Microsoft, c'est que les deux premiers ont un très bon historique dans la communauté du libre.
Tu as l'air de t'offusquer qu'on puisse ne pas faire confiance à Microsoft ! Ca me parait pourtant une attitude naturelle compte tenu de leur historique
> KDE a aussi fait quelques erreurs [...] mais et une bonne solution a été trouvée à chaque fois
Exception : arts. Je ne sais pas pourquoi KDE traine encore ce truc mais ce n'est pas du tout dans la ligne du reste de KDE. J'espere qu'ils s'en débarasseront un jour et qu'ils passeront a gstreamer.
> Corba et bonobo sont toujours là et il n'y a rien qui indique que ça va être viré.
De fait. Je pense que ca continue à freiner le développement de Gnome mais je n'ai pas dit que ça allait être viré. Pendant que Michael Meeks codait bonono pendant ses un à deux ans (parce que c'est une grosse bete), les hackers KDE faisaient avancer KDE.
> Il n'y a pas un début d'embryon de discussion pour changer de language pour les librairies.
Je n'ai rien dit de tel non plus. Gnome va rester en C et là aussi, je pense que ca ne contribue pas à accelérer son développement. Pendant que Owen (c'est bien lui) codait GObject pendant 6 mois, les hackers KDE faisaient avancer KDE.
> C# est comme python, C++, perl, ada, ... pour Gnome. C'est un binding et c'est tout.
Oui. Ai-je dit le contraire ? J'ai l'impression que tu te trompes de Troll. Ici, c'est pas << Gnome va être ré-écrit en C# >>, c'est << MDI change d'avis tous les deux ans et fout les projets auquels il participe dans la merde avant de se barrer >>
> gtk# c'est pas la réécriture de gtk en C# par exemple ! C'est un binding comme un autre.
Yeps. Comme Qt#. Mais je vois pas le lien avec la discussion que j'ai eu plus haut.
> C'est vrai que tous les développeurs Gnome sont des cons et suive le gourou MDI sans réfléchir.
En tout cas, ils ont tous mordu à l'hameçon Corba alors que c'était une grosse connerie et qu'ils en avait la preuve juste sous les yeux. Et oui, MDI a du charisme et a entrainé beaucoup de gens avec lui, notamment dans Gnome, avant de les laisser dans la merde et de commencer un autre projet.
Même RMS y a cru. Lors de l'interview que KDE France a fait de lui à la linux expo 2003, il a dit qu'il regrettait d'avoir autant suivi Miguel et qu'il voulait maintenant se rapprocher plus de KDE.
> D-BUS est plus simple et n'a pas les objectifs de Corba et ne remplacera pas Bonobo.
Heureusement qu'il n'a pas les objectifs de Corba parce Corba est compètement indadapté aux besoins d'un protocole de communication inter-application de bureau. D-BUS a les objectifs de servir de protocole de comme entre les applis de bureau et le matériel. En ce sens, il va un poil plus loin que DCOP mais à l'époque ou DCOP a été concu, l'USB et le hotplug était de la science fiction donc on peut comprendre qu'ils n'ont pas abordé cette problèmatique de front.
D-BUS ne remplacera pas Bonobo en effet. Pour remplacer bonobo, il faut DCOP + KPart, c'est à dire un protocole de communication + une système de composant. Tout est déjà présent dans Gtk et dans Gnome pour faire un équivalent de KPart bcp plus léger que bonobo. En fait, en tant que simple programmeur KDE, j'ai réussi à faire un composant pour une application Gtk (gvim) en passant par des GtkSocketPlug. Donc un hacker Gnome, si il lui en prenait l'envie, serait probablement capable de cracher un système de composant léger en moins d'une semaine, le temps qu'il a fallu pour faire kpart. On attendra encore un ou deux ans pour que ça arrive, le temps qu'ils se désintoxiquent compètement de Corba et qu'ils oublient que KDE a déjà la solution.
> Premièrement ton truc au-dessus est bourré de connerie.
Pour l'instant, on peut pas dire que tu as avancé un seul argument qui tienne la route pour me donner tort, au contraire.
> Deuxièmement MDI ne s'occupe plus de Gnome depuis la version 2.0.
De fait. C'est ce que je soulignais en disant que MDI change d'avis tous les deux ans et laisse les projets en plan.
MDI a ça pour lui que quand un projet commence à être dans la merde, il se barre en douce. Ca m'étonne pas qu'il soit plus dans Gnome. Il faudra plusieurs années à Gnome pour se remettre de sa présence mais le projet redécollera peut-être.
> 2) Le choix du C c'est pas pour faire warlordz, c'est parce qu'on peut plus facilement faire des bindings faire d'autres langages.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.
Je ne lui reproche pas d'évoluer et de changer d'avis. C'est une qualité d'être capable de revenir sur ses actes et de reconnaitre ses erreurs. Par contre, quand on entraine avec soi tout un projet de la taille de Gnome, on est prié de reflechir bien au futur et à toutes les solutions existantes. Ce qu'il n'a pas fait.
Je lui reproche de prendre en moyenne 2 ans pour s'apercevoir qu'il s'était complètement planté alors que la solution était la sous ses yeux et qu'il a refusé de l'utiliser. L'exemple de corba est tres parlant et ce n'est pas le seul. KDE a été hué et critiqué énormement pour leur absence de reflexion quand ils ont laché corba. Pourtant, n'importe qui prenant la peine d'analyser les raisons qui les ont pousser à rejeter Corba et à choisir une solution DCOP + KPart aurait vu que leurs raisons étaient tout à fait valides et que Gnome allait rencontrer les mêmes problèmes. Mais visiblement, _personne_ chez Gnome n'a pris la peine de faire ces démarches et bonobo reste une usine à gaz.
Pour ce qui est de la communication entre applications, Gnome reste très pauvre alors qu'on peut scripter n'importe quelle application KDE avec DCOP. D-BUS semble apporter une solution un peu plus riche et ô surprise, c'est un DCOP sans la dépendance X. Là encore, on frise les 4 ans pour s'apercevoir de l'interêt d'une technologie pourtant déjà mature dans un projet qu'ils ont sous les yeux. Si tu regardes les arguments qui sont utilisés pour D-BUS, ce sont les mêmes qui ont été avancé à l'époque où KDE 2 n'était même pas encore sorti.
Donc faire des erreurs, je veux bien. Mais être aussi aveugle, je pense qu'il faut vraiment y mettre de la mauvaise volonté. Apparemment, toute la clique Ximian lorgne maintenant beaucoup plus du côté de Microsoft que du côté de KDE.
KDE a aussi fait quelques erreurs mais la très grosse différence, c'est que des personnes qui réflechissaient objectivement (et pas en terme hype ou en lisant les press release de Microsoft) à tous les problèmes et les avantages d'une solution ont participé à la reflexion et qu'une bonne solution a été trouvée à chaque fois. La meilleure preuve, c'est qu'ils n'ont rien changé depuis 4 ans à dcop et kpart.
KDE a aussi choisi Corba mais s'est rendu compte de son erreur en moins d'un an. De plus, le projet a gardé la même ligne de conduite depuis sa création alors que Miguel n'a cessé de changer d'avis tous les deux ans comme je le soulignais là-haut. L'avantage, c'est que le projet a pu avancer de façon cohérente, alors que Gnome se disperse beaucoup et que beaucoup d'appli soi-disant Gnome sont en fait soit des applis Gtk, soit des applis Gnome 1, soit (pire) des applis Gtk 1. Bref, ca contraste beaucoup avec KDE et sa ligne de conduite claire.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Oui, mais beaucoup de slots predefinis sont suffisants. Typiqueemnt, pour un dialogue de configuration ou certains checkbox et combo vont activer ou desactiver d'autres widgets, tu peux faire tout avec Qt Designer puisque tu vas utiliser des signaux et des slots existants. Je trouve ca plus fun que de le faire dans le code.
> > Glade ne permet que de reagir en terme d'evenements (j'ai clique ici, appelle moi cette fonction)
> Si. Faut regarder dans les propriétés de l'object.
J'ai pas vu ou pas compris comment il fallait faire. On peut choisir de connecter un signal a un callback, mais pas un signal a callback d'un autre objet. Ou en tout cas, j'ai pas compris comment il fallait faire. Je voudrai faire l'exemple plus haut, ou un combo-box met a jour un champ textedit. A la rigueur, si tu peux le faire, envoie-le moi par mail, ca m'interesse.
Pour l'absence des widgets Gnome, c'est parce que ma gentoo a pris mon setting par defaut qui est sans gnome.
> J'ai cree un combo-box mais je ne peux pas le remplire.
Correction, je peux remplire la combo-box. Le lien "Edit Menu" n'est pas tres parlant. En revanche, je n'ai pas pu remplire la GtkTreeView
Donc une impression moins negative que la premiere fois mais quand meme, c'est pas encore ca.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
k=konqueror-2775; for i in `dcop $k | grep html-widget`; do dcop $k $i url; done
Pour l'autre, j'ai fait une astuce a l'epoque:
http://linuxfr.org/tips/176.html(...)
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 0.
> Les composans sont chargés par le programme comme une librairie.
Juste pour rire, combien d'annees-hommes depensees dans Bonobo pour lui faire faire au final la meme chose que dlopen ? Au moins une et demi, celle de Michael Meeks. A mon avis, c'est beaucoup plus. Donc en fait, on super-corba et super-bonobo mais on fait la meme chose que dlopen. Trop fort!
> Es-ce que les utilisateurs trouvent KDE plus rapide ou plus léger que Gnome ?
Oui.
Mais les utilisateurs de Gnome trouvent aussi Gnome plus rapide que KDE. Donc tout ca est tres subjectif. Et a part des arguments subjectifs, je ne t'ai pas vu contribuer grand chose a cette conversation, si ce n'est ton soutien presque inconditionnel a Gnome.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 0.
C'est vrai que cet aspect est un peu plus difficile a avoir. Mais peux-tu me citer des composant bonobo OCaml, python et perl ? Ben y en pas, c'est plutot rare comme besoin.
Pour faire des composants dans un autre langage, c'est un poil plus dur puisqu'il faut commencer par faire une espece de chargeur de composant dans le nouveau langage en kpart et ensuite faire des composants pour ce chargeur. C'est deja fait pour le python, ce sera fait pour les autres langages quand les gens en auront besoin. Pour l'instant, le besoin n'est pas tres present.
> Oui mais là tu n'as plus de communication entre tes machins, il faut mettre en place de l'IPC séparément.
Le plus simple est de choisir DCOP. Soit tu utilises la lib existante (binding presents en C, C++, bash, python, perl, ruby, java), soit tu te refais le marshalling dcop qui est documente.
Meme comme ca, je pense que c'est moins lourd que Bonobo a utiliser
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 0.
A cote, KDE reussi a sortir un navigateur, un IDE, une suite de communication integree, une suite office. Et pourtant, il y a une demi-personne payee sur konqueror (maintenant, c'est 0 personnes payees), une demi personne payee sur KOffice (avant, c'etait une personne), une personne payee sur toutes la partie config/backend et une autre personne payee pour faire ce qu'elle veut.
Le reste, c'est pris sur le temps libre.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Et on dit que c'est KDE qui ressemble a Windows...
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
Si Microsoft avait un truc propre ou chaque programme avait une zone reservee en dehors de laquelle il n'a pas a ecrire, on aurait moins de probleme.
Tu vas me dire que c'est ce qu'a fait Microsoft mais que c'est le vilains programmes qui font pas ce qu'il faut. Mais bon, je ne prends pas. Si Microsoft avait bien fait son boulot, les problemes de base de registre aujourd'hui, on n'en aurait pas.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à -2.
Pourtant, quand on fait le rapport avec les 0 machines linux infectées, ça fait un putain de ratio.
Quand on pense que toutes ces machines sont infectées a cause de la nullite des logiciels Microsoft, ça fait pleurer.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
70% des logiciels sous windows te demandent de rebooter après une installe. Sous les anciennes versions de windows, tu rebootais pour un oui ou pour un non (je change mon adresse IP, je reboote).
[^] # Re: Combien de temps avez-vous mis avant de maîtriser Linux ?
Posté par Philippe F (site web personnel) . En réponse au sondage Combien de temps avez-vous mis avant de maîtriser Linux ?. Évalué à 2.
"Bat souvent ton windows car si tu ne sais pas pourquoi tu le bats, lui, il le sait".
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Qu'en est-il si tu veux agir sur un objet qui n'est pas une option ? L'autre jour par exemple, j'ai ecrit un script bash + dcop pour recuperer les URLs de tous les onglets ouverts dans konqueror. Je m'en suis servi aussi pour envoyer des commandes dans plusieurs onglets d'une konsole via un script bash. Pour ce genre d'utilisation avancee, je ne pense pas que gconftool suffise.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Je viens d'utiliser glade (version 2.0) pour voir et il manque pas mal de chose pour en faire un outil aussi bon que Qt Designer.
Comment je fais pour connecter un signal a un slot ? Glade ne permet que de reagir en terme d'evenements (j'ai clique ici, appelle moi cette fonction), facon visual basic mais il ne permet pas de faire plus.
En une minute de Qt Designer, tu peux faire un combo-box qui met a jour un champ edit en fonction de l'item selectionne dans la combo (connecter le signal activated(QString) du combo au slot setText( QString) du texteedit) mais faire la meme chose sous glade ne me semble pas possible. L'exemple combo est relativement simple, en general, j'utilise Qt Designer pour faire des trucs quand meme plus complexes, avec des combo qui invalident les widgets, des check box qui cachent des widgets. Tout ca doit se faire cote code avec glade.
Il ne m'a pas semble voir les widgets specifiques Gnome. On ne peut faire que du Gtk avec glade ?
J'ai cree un combo-box mais je ne peux pas le remplire. Idem pour un GtkTreeView, impossible d'ajouter des elements dedans. J'en conclus qu'on ne peut avoir que des widgets vides. Plutot decevant.
Comment je fais pour choisir l'ordre de la navigation clavier avec tab ?
Pour ce qui est de l'aide, l'onglet Help de glade ne contient que un miserable dialgue 'about glade'. Quid d'un tutorial ou d'un document d'aide ? C'est d'autant plus dommage que le systeme de gestion de l'aide est vraiment tres bien fait sous Gnome et je trouve l'afficheur plus joli et plus fonctionnel que celui de KDE. Le site web est lui-meme tout aussi pauvre en documentation.
En resume, je comprends que tu n'aies pas vu de grande difference entre glade et Qt Designer si tu passes du premier au second mais dans l'autre sens, la transition est difficile.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
C'est sur que pour des familiers de Corba comme toi, c'est decevant. Mais vraiment, le besoin en question n'est pas Corba.
Pour ce qui est de la distribution de gconf en reseau, c'est en effet une problematique interessante. Mais il suffit de modifier un tout petit peu gconf pour le faire, pas besoin de faire rentrer corba dans toutes les applications.
Sinon, DCOP ne signifie pas en effet que Corba est exclu, c'est juste que c'est pas le mecanisme par defaut. Il serait tres facile en effet de generer des composants Corba a partir des informations fournies par DCOP. Personne ne l'a fait jusqu'a present, probablement parce que personne n'en a besoin.
Dans le meme ordre d'idee, il serait relativement facile de faire un pont bonobo - kpart. Mais personne n'en a besoin.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
La force de Corba, c'est:
- composant independant de la plate-forme
- composant independant du langage
- distribution des composants sur plusieurs machines
Ces avantages ont evidemment un cout:
- toutes les communications entre composant se font par un IDL et via le reseau. Declarer les interfaces est assez lourd
- parce que les composants sont reclames a un serveur, ca prend pas mal de temps d'activer un composant
- l'ensemble du framework est relativement lourd a apprendre, a installer et a gerer
- la consommation memoire du tout n'est pas forcement negligeable. Le marshalling et la communication reseau introduisent des delais
- le debug de tout ca est une horreur. Quand le serveur tombe, il te reste plein de processus en background a tuer.
Apres une reflexion de fond, il apparait que les besoins en terme de communication pour un bureau comme KDE sont:
- pouvoir notifier toutes les applications d'un evenment facilement (ejection du lecteur CD, nouveau mail, application lancee, ...)
- d'etablir des canaux de communication entre applications pour echanger des informations relativement simples (ouvre moi cette page web, affiche moi le lien bidule dans la barre d'etat, ...)
- faire des requetes sur les applications : donne moi la liste de tous les composants editeur de texte, dis moi si kmail est deja lance, ...
Tout ca devant s'executer relativement rapidement puisqu'il y a une interaction avec l'utilisateur.
Cote composant graphique, les besoins sont:
- etre capable d'associer un role a un composant et de faire des recherches par role
- charger le composant tres rapidement de facon a ce que l'utilisateur ne voit pas qu'il y a une distinction entre l'application (konqueror) et le composant (khtml).
- avoir une structure globale tres legere pour que ca se charge vite
- le tout doit etre facile a apprendre de facon a ce que les developpeurs qui travaillent sur leur temps libre puisse facilement ecrire des composants.
En regardant ces listes, on voit que les points forts de Corba ne font par partie des besoins, alors que certaines de ses caracteristiques vont poser des problemes. Typiquement, sur un bureau, toutes les applications du bureau sont lancees par le meme utilisateur, sur le meme ordinateur. L'idee d'avoir un konqueror ou le composant khtml serait en train de s'executer sur un autre ordinateur parait un peu incongru. Le besoin de travailler sur plusieurs ordinateurs en meme temps est deja rempli par X ou par vnc.
Donc je ne crache pas sur Corba en general, mais sur cette application de Corba en particulier. Les technos developpes par KDE lorsqu'ils se sont rendu compte de la problematique que je viens d'exposer (c'est pas moi qui l'ai invente, je l'ai lue) repondent parfaitement aux besoins enonces avec rien de trop:
- DCOP est leger et permet de faire tout ce qui est dit
- kpart est leger, ca se charge tres vite puisque c'est une bibliotheque partagee
- pour ce qui est de la communication entre le composant et son applciation, on utilise un simple appel de fonction C++ puisque le composant est charge directement dans l'espace d'adressage de l'application
- pas de marshlling
- hyper simple a utiliser, pas d'IDL, pas de doc speciale a lire, tout marche avec du C++ normal: l'appli doit heriter de kparthost et le composant de kpart.
Et pour les "oui mais si jamais je veux quand meme avoir un composant independant de l'appli qui l'embarque", c'est encore possible. Gtk et Qt implementent tous les deux un mecanisme qui permet d'incruster n'importe quelle fenetre X dans une autre fenetre (XEmbed). C'est ce qu'on utilise pour kvim. Avec ca, on peut lancer un programme quelconque sur une machine distante via le serveur X et l'utiliser comme composant.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Tu peux lire l'intro de DCOP pour retrouver un peu les problèmes :
http://developer.kde.org/documentation/library/kdeqt/dcop.html(...)
http://developer.kde.org/documentation/books/kde-2.0-development/ch(...)
On voit bien que Corba ne répondait pas à la problèmatique pour laquelle on voulait l'utiliser. Un des premiers paragraphes du tutorial de bonobo contient une phrase du type << bonobo peut via corba afficher dans une application un composant graphique executé sur une autre machine et ecrit dans un autre lanage. Il doit y avoir quelqu'un sur terre qui a besoin de cette fonctionnalité >>
Pour moi, ca souligne que l'interet principal de Corba (la distribution de composants sur plusieurs machines) ne trouve pas d'utilité ni dans Gnome, ni dans KDE. Donc pourquoi s'embarasser de Corba ?
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
J'ai pas dit que c'était nouveau, j'ai dit que c'etait là.
> C'est révolutionnaire
Je ne pense pas non.
> De plus le C ce n'est pas un language de merde
Non. Même, je vais te surprendre mais j'aime bien coder en C. Par contre, coder un Gtk n'a pour moi rien à voir avec du C. Quand je fais des classes, de l'héritage et que je manipule le concept de surcharge de méthode, je préfère utiliser un langage objet où ces paradigmes font partie du langage et ne sont pas rajoutés à coup de bricolage macroesque incertain.
Pour ce qui est de la programmation d'interface graphique, je pense que le C est << un langage de merde >> pour reprendre tes mots. Et ce pour les raisons que je viens d'évoquer.
L'idée de mon post était de rappeler qu'en terme de facilitation de développement d'applications graphiques, KDE a pas mal de mécanismes, la plupart basés sur XML, qui permettent de faire beaucoup de choses de façon automatisée (génération automatique de stub pour dcop) et que au lieu de lorgner en permanence du côté de Microsoft pour de l'innovation, la ximian team ferait bien de regarder de plus pres ce qu'il y a dans KDE et dans les autres projets comme GnuStep.
> Et il a raison sur la proposition d'avoir un language de script central
Malheureusement, ca ne sera pas possible dans la communauté du libre car chacun a son langage de script favori et aucun ne peut vraiment l'emporter. Pour les emacsien, c'est le lisp, RMS recommande le scheme, certains penchent pour python, d'autre ruby, d'autres perl, d'autre Javascript, d'autre C#, lua, Objective Caml, ...
C'est plus facile coté microsoft puisque tout le monde boit ce que dit Bill Gates. A noter quand meme que pendant longtemps, le basic VB etait incompatible avec le basic Access, lui-même incompatible avec sa version précedente, et que tout ca est incompatible avec le basic VB.NET . Bref, faut pas croire que tout est aussi rose que le marketing veut bien le dire. Je me demand même si on n'a pas la vie plus simple, parce qu'au moins, on sait à l'avance que python ne veut pas dire perl.
Ce qui est important, c'est en terme de diversité de langage, c'est que chacun aie accès de la même façon au coeur Gnome ou KDE. La seule facon de garantir cela, c'est de générer automatiquement les bindings comme le font aujourd'hui KDE et Gnome.
> Gnome est toujours là et en pleine forme.
Il est toujours là mais pour moi, il n'est pas en pleine forme. Il a coûté beaucoup plus cher que KDE et terme de mois-hommes. Et quand on regarde les rouages, KDE est beaucoup plus avancé. En trois lignes de bash, je peux m'amuser à faire un fond d'écran dynamique avec mes photos de vacances, sans aucune connaissance précise sur KDE en dehors du fait de taper kdcop.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
La situation devrait s'améliorer avec Fedora qui a l'air beaucoup moins fermée que ne l'était Redhat.
> Compare avec la doc, il en manque plein.
Je sais pas si ils y sont tous, j'ai juste dit que aucun ne m'avait manqué. J'ai réussi à faire exactement ce que je voulais sans ressentir de limitation. Lequels t'ont manqué ?
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 0.
Tu as l'air de t'offusquer qu'on puisse ne pas faire confiance à Microsoft ! Ca me parait pourtant une attitude naturelle compte tenu de leur historique
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
Exception : arts. Je ne sais pas pourquoi KDE traine encore ce truc mais ce n'est pas du tout dans la ligne du reste de KDE. J'espere qu'ils s'en débarasseront un jour et qu'ils passeront a gstreamer.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 4.
Lesquelles ?
> Corba et bonobo sont toujours là et il n'y a rien qui indique que ça va être viré.
De fait. Je pense que ca continue à freiner le développement de Gnome mais je n'ai pas dit que ça allait être viré. Pendant que Michael Meeks codait bonono pendant ses un à deux ans (parce que c'est une grosse bete), les hackers KDE faisaient avancer KDE.
> Il n'y a pas un début d'embryon de discussion pour changer de language pour les librairies.
Je n'ai rien dit de tel non plus. Gnome va rester en C et là aussi, je pense que ca ne contribue pas à accelérer son développement. Pendant que Owen (c'est bien lui) codait GObject pendant 6 mois, les hackers KDE faisaient avancer KDE.
> C# est comme python, C++, perl, ada, ... pour Gnome. C'est un binding et c'est tout.
Oui. Ai-je dit le contraire ? J'ai l'impression que tu te trompes de Troll. Ici, c'est pas << Gnome va être ré-écrit en C# >>, c'est << MDI change d'avis tous les deux ans et fout les projets auquels il participe dans la merde avant de se barrer >>
> gtk# c'est pas la réécriture de gtk en C# par exemple ! C'est un binding comme un autre.
Yeps. Comme Qt#. Mais je vois pas le lien avec la discussion que j'ai eu plus haut.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
En tout cas, ils ont tous mordu à l'hameçon Corba alors que c'était une grosse connerie et qu'ils en avait la preuve juste sous les yeux. Et oui, MDI a du charisme et a entrainé beaucoup de gens avec lui, notamment dans Gnome, avant de les laisser dans la merde et de commencer un autre projet.
Même RMS y a cru. Lors de l'interview que KDE France a fait de lui à la linux expo 2003, il a dit qu'il regrettait d'avoir autant suivi Miguel et qu'il voulait maintenant se rapprocher plus de KDE.
> D-BUS est plus simple et n'a pas les objectifs de Corba et ne remplacera pas Bonobo.
Heureusement qu'il n'a pas les objectifs de Corba parce Corba est compètement indadapté aux besoins d'un protocole de communication inter-application de bureau. D-BUS a les objectifs de servir de protocole de comme entre les applis de bureau et le matériel. En ce sens, il va un poil plus loin que DCOP mais à l'époque ou DCOP a été concu, l'USB et le hotplug était de la science fiction donc on peut comprendre qu'ils n'ont pas abordé cette problèmatique de front.
D-BUS ne remplacera pas Bonobo en effet. Pour remplacer bonobo, il faut DCOP + KPart, c'est à dire un protocole de communication + une système de composant. Tout est déjà présent dans Gtk et dans Gnome pour faire un équivalent de KPart bcp plus léger que bonobo. En fait, en tant que simple programmeur KDE, j'ai réussi à faire un composant pour une application Gtk (gvim) en passant par des GtkSocketPlug. Donc un hacker Gnome, si il lui en prenait l'envie, serait probablement capable de cracher un système de composant léger en moins d'une semaine, le temps qu'il a fallu pour faire kpart. On attendra encore un ou deux ans pour que ça arrive, le temps qu'ils se désintoxiquent compètement de Corba et qu'ils oublient que KDE a déjà la solution.
> D-BUS c'est IPC avec un deamon.
Tout comme dcop. Un IPC et un demon. Pour ton info: http://developer.kde.org/documentation/library/kdeqt/dcop.html(...)
> Premièrement ton truc au-dessus est bourré de connerie.
Pour l'instant, on peut pas dire que tu as avancé un seul argument qui tienne la route pour me donner tort, au contraire.
> Deuxièmement MDI ne s'occupe plus de Gnome depuis la version 2.0.
De fait. C'est ce que je soulignais en disant que MDI change d'avis tous les deux ans et laisse les projets en plan.
MDI a ça pour lui que quand un projet commence à être dans la merde, il se barre en douce. Ca m'étonne pas qu'il soit plus dans Gnome. Il faudra plusieurs années à Gnome pour se remettre de sa présence mais le projet redécollera peut-être.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Je lui reproche de prendre en moyenne 2 ans pour s'apercevoir qu'il s'était complètement planté alors que la solution était la sous ses yeux et qu'il a refusé de l'utiliser. L'exemple de corba est tres parlant et ce n'est pas le seul. KDE a été hué et critiqué énormement pour leur absence de reflexion quand ils ont laché corba. Pourtant, n'importe qui prenant la peine d'analyser les raisons qui les ont pousser à rejeter Corba et à choisir une solution DCOP + KPart aurait vu que leurs raisons étaient tout à fait valides et que Gnome allait rencontrer les mêmes problèmes. Mais visiblement, _personne_ chez Gnome n'a pris la peine de faire ces démarches et bonobo reste une usine à gaz.
Pour ce qui est de la communication entre applications, Gnome reste très pauvre alors qu'on peut scripter n'importe quelle application KDE avec DCOP. D-BUS semble apporter une solution un peu plus riche et ô surprise, c'est un DCOP sans la dépendance X. Là encore, on frise les 4 ans pour s'apercevoir de l'interêt d'une technologie pourtant déjà mature dans un projet qu'ils ont sous les yeux. Si tu regardes les arguments qui sont utilisés pour D-BUS, ce sont les mêmes qui ont été avancé à l'époque où KDE 2 n'était même pas encore sorti.
Donc faire des erreurs, je veux bien. Mais être aussi aveugle, je pense qu'il faut vraiment y mettre de la mauvaise volonté. Apparemment, toute la clique Ximian lorgne maintenant beaucoup plus du côté de Microsoft que du côté de KDE.
KDE a aussi fait quelques erreurs mais la très grosse différence, c'est que des personnes qui réflechissaient objectivement (et pas en terme hype ou en lisant les press release de Microsoft) à tous les problèmes et les avantages d'une solution ont participé à la reflexion et qu'une bonne solution a été trouvée à chaque fois. La meilleure preuve, c'est qu'ils n'ont rien changé depuis 4 ans à dcop et kpart.
KDE a aussi choisi Corba mais s'est rendu compte de son erreur en moins d'un an. De plus, le projet a gardé la même ligne de conduite depuis sa création alors que Miguel n'a cessé de changer d'avis tous les deux ans comme je le soulignais là-haut. L'avantage, c'est que le projet a pu avancer de façon cohérente, alors que Gnome se disperse beaucoup et que beaucoup d'appli soi-disant Gnome sont en fait soit des applis Gtk, soit des applis Gnome 1, soit (pire) des applis Gtk 1. Bref, ca contraste beaucoup avec KDE et sa ligne de conduite claire.