J'ai dit que Redhat avait un mauvais historique avec KDE. Ca s'est peut-etre ameliore. Le probleme du non-packaging des versions de correction de bug de KDE est quand meme loin d'etre petit.
Il s'est pose plusieurs fois la question a l'interieur de KDE de citer officillement les distributions supportant KDE (comprendre, l'installant correctement) d'ou Redhat aurait ete exclu.
> Je suis en français dans KDE et tout est absolument normal.
Gnome est base sur Gtk donc si Gtk a des problemes, Gnome a des problemes.
Pour ce qui est de libgnomeui, ce ne sont que quelques widgets Gnome specifiques. L'essentiel de la partie graphique de Gnome est en Gtk. D'ailleurs, pendant la transition Gnome 1/Gtk 1 -> Gnome 2/ Gtk 2, pas mal de widgets Gnome sont rentres de Gtk.
Il faudrait peut-etre se renseigner avant de parler.
Tout a fait. Chacun est libre de soutenir qui il veut.
La difference entre nous, c'est que d'une part, je me suis quand meme pas mal penche sur Gnome pour voir ce qu'il avait sous le capot, notamment suite aux critiques que KDE a recu. D'autre part, je me suis aussi pas mal penche sur KDE. Mon soutien a KDE n'est pas inconditionnel (ou en tout cas, pas seulement), il est fonde sur ce que j'ai vu de la facon de travailler sur le projet et de ce qu'il a sous le capot. Pour info, j'ai voulu regarder de pres, j'ai ecrit des applications Gtk, j'ai ecrit un composant bonobo pour voir, j'ai lu des listes de dev pour voir les problemes qui se posaient sous Gnome et sous KDE. Mon troll a des fondations solides.
> Votre méthode pour soutenir KDE c'est de descendre Gnome
C'est plutot que quand je vois des gens qui soutiennent Gnome, je me ressens le besoin de les informer d'une part sur les problemes de Gnome, d'autre part sur l'interet de KDE. Je le fais de facon plus ou moins objective, en avancant en tout cas des arguments que je juge valide. Et meme plus le temps passe, plus mes arguments se verifient.
Je trouve que tu manques d'arguments techniques pour contrer nos critiques. Et je pense qu'il est vraiment beaucoup plus difficile de critiquer KDE que Gnome. En general, les critiques ne depassent pas le "Qt c'est pas libre" et "Si Microsoft rachete Trolltech, KDE est dans la merde" qui sont demontees en deux phrases et deux liens.
DCOP est evidemment moins puissant que Corba, mais si tu as bien lu ce que j'ai dit plus haut, c'est justement son interet. Moins puissant, moins lourd, plus adapte a la tache.
> Y'a deux côtés dans une comunication.
Tout a fait. Cote communication, DCOP gere les deux direction pour l'IPC. Pour l'aspect graphique, KPart marche dans les deux sens. Aujourd'hui, on peut utiliser PyKDE et charger des composants KPart ecrits en C++ ou en python. Et on peut aussi utiliser KDE normal pour charger des composants KPart ecrits en C++ ou en python.
Pour ce qui est des autres langages, il ne reste qu'a ecrire le chargeur mais vraiment, ca n'est pas complique. J'ai reussi a en faire un bout alors que je n'y connaissais rien.
TheKomany n'a jamais rien contribue d'util a KDE. La plupart de leurs produits sont close-source et payants, sauf ceux qu'ils ont recuperes de projets libre ou ils n'ont pas le choix de la licence.
Les contrats Kolab et Kroupware sont tres recents, ils ont moins d'un an. Avant ca, KDE a avance sans pratiquement aucun soutien financer.
En revanche, c'est vrai que j'ai oublie l'acteur le plus influent sur KDE: Trolltech. Mine de rien, KDE doit son succes a Trolltech, grace a la qualite de Qt. Mais ca, c'etait dans le contrat de depart: Mathias Ettrich dans le post fondateur dit que Qt lui semble la meilleure bibliotheque pour lancer KDE.
Trolltech a une equipe d'ingenieurs (environ 40 personnes il me semble) qui bossent a plein temps sur Qt. Une grosse partie de leur temps est passe sur des trucs qui n'apportent rien a KDE (portage sur des vieux unix a la con, portage sous windows, integration des active X, integration des applis Motifs, XEmbed, TeamBuilder, Qt Embedded, Qt Mac, ...) mais quand mais ils permettent clairement a KDE de se concentrer uniquement sur la partie uniquement desktop.
Cote Gtk, il y a surtout Redhat et Ximian. Donc je modere mon propos.
> il est fou de constater que même les développeurs KDE, aujourd'hui, des années après, ne sont toujours pas prêts à accepter qu'utiliser
> KDE avec Qt jusqu'à Qt 2.2 était simplement illégal
C'est fou ce que le FUD a la vie dur. Les seuls a avoir clame que Qt et KDE etait illegal sont Debian et Redhat. Pour Redhat, ca ne les a pas empeche de l'inclure dans leur distrib un an plus tard ce qui discredite quand meme pas mal leur argument.
Donc reste debian.
A cote de ca, les avocats de Suse, de Mandrake, de Trolltech se sont penches sur le probleme et ont conclu qu'il n'y en avait pas. RMS lui-meme a dit qu'il etait Ok, bien qu'il n'aimait pas trop le principe de distribution des modifications par patch.
Mais bon, si tu t'y connais mieux en licence que les avocats de trois boites majeurs de libre et que RMS, tu peux dire que KDE avait des pratiques illegales.
La seule chose qu'on peut dire objectivement, c'est que seul un tribunal aurait pu trancher la legalite de la chose.
> Maintenant si tu connais une technique miraculeuse pour qu'un OS puisse detecter quel process a le droit d'ecrire ou, je serais ravi que tu me la donnes.
Yeps. Et c'est plus ou moins utilise par Apple il me semble. Le principe, c'est de ne donner qu'un seul repertoire a un programme pour installer ce qu'il a besoin d'installer: ses fichiers de conf, ses extensions, ses comopsants COM, son option de demarrage automatique.
Le fait d'avoir un repertoire unique par programme fait que lorsque tu veux effacer le programme, il te suffit d'effacer le repertoire dans lequel il a installe tout ca.
Pour ce qui est de la coherence de l'ensemble, le systeme doit balayer regulierement l'ensemble de tous les repertoires de programme pour voir si de nouveaux programmes ont ete installes ou si des options de certains programmes ont ete change (info accessible par exemple avec la derniere date de modif du repertoire)
Comment fait le systeme pour retrouver ses petits apres ? Il faut que dans le repertoire du programme, il y aie une convention de nommage qui permet de savoir ce que le programme a installe.
Il faut prevoir deux vues de cette base, une vue par programme pour savoir quels sont tous les attributs d'un programme et une vue systeme qui correspond plus a la base de registre actelle: qui demarre automatiquement, quels sont les composants COM isntalles, ....
Note que pour ce genre de systeme, l'utilisation de lien symbolique comme elle existe sous Unix permet de gerer entierement ce systeme au dessus d'un systeme de fichier existant.
Au final, on obtient une sorte de base de registre avec les proprietes suivantes:
- chaque programme est bien isole et facile a effacer, analyser, ...
- on a les memes services que la base de registre actuelle.
La seule operation que pourrait faire un programme, c'est demander un nouveau repertoire a la base de registre et installer ses saloperies dedans.
Le systeme que je decris n'est pas present de base sous Linux mais un mec a commence une refonte dans ce sens et ca se passait pas mal.
> Les serveurs Linux qui envoient du spam chaque jour ils sont tout propre aussi hein ?
On parlait de virus. Tu sais, le truc ou si tu recois un windows par defaut avec outlook par defaut, tu vas te prendre tous les virii de la terre et les renvoyer a tout le monde. Mais ca n'a rien a voir avec Microsoft.
> > Quand on pense que toutes ces machines sont infectées a cause de la nullite des logiciels Microsoft, ça fait pleurer.
> Ouais c'est vrai, heureusement Linux il est beau et il n'a jamais de failles, d'ailleurs les serveurs de Gentoo, Gnu.org, sourceforge, tuxfamily, etc... sont la pour le prouver.
Je fais une distinction entre le fait d'avoir des bugs dans un programme, ce qui est comprehensible et le fait d'avoir un checkbox dans outlook "executer automatiquement des macros" qui se traduit en francais par "je veux que mon ordinateur soit facilement et automatiquement infecte par des virus" configure par defaut.
Globalement, depuis 10 ans, la politique securite de Microsoft est un vrai scandale, alors meme que ses programmes equipent 99.99% des machines. Je pense que le terme irresponsable convient bien a cette boite. Depuis deux ou trois ans, ils essayent de redresser la barre mais c'est bien tard.
Et pour l'histoire du Tuxfamily et consort, ca n'a rien a voir dans la mesure ou c'est une attaque ciblee contre une machine precise.
Je suis pas un expert sur ces problematiques, mais je sais qu'ils ont fait des trucs chiant. Genre je renomme tous les modules du centre de controle, ce qui fait que si une appli exterieur veut incruster un module du centre de controle sous Redhat elle va planter.
Il y a eu aussi enormement de problemes autour de l'internationalisation. Redhat livrant majoritairement aux americains, il s'en foutent un peu des accents et des conneries comme ca. Donc KDE sur Redhat etait en general dysfonctionnel au niveau de la gestion de l'internationalistion.
Il y a eu une epoque ou ils avaient change le fonctionnement de kppp de sorte que la doc ecrite en 47 langues n'etait plus valable. C'est la coordinatrice de la documentation qui etait contente!
On peut citer aussi le fait qu'ils ne packagent jamais les versions mineures de KDE donc les utilisateurs ne peuvent pas faire des mises a jour de correction de bug.
Et puis il y a eu les problemes quand ils ont livre un snapshot de gcc non release qui foutait la merde au niveau de la compile et de la compabilite binaire.
La suppression du 'About KDE' n'est pas tres bien passe non plus.
Pour tous ces problemes, la reponse de Red Hat a toujours ete aux developpeurs KDE a ete : allez vous faire foutre.
Donc a chaque fois que RedHat fait qqch avec KDE, on s'attend au pire meme si pour l'instant, il n'est pas arrive. Il y a eu un troll sur le fait que leur beta 9 ne contenait pas KDE qui s'est avere infonde.
> 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.
[^] # 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.
Il s'est pose plusieurs fois la question a l'interieur de KDE de citer officillement les distributions supportant KDE (comprendre, l'installant correctement) d'ou Redhat aurait ete exclu.
> Je suis en français dans KDE et tout est absolument normal.
alors, KDE 3.2.1 marche bien pour toi ?
[^] # 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.
Pour ce qui est de libgnomeui, ce ne sont que quelques widgets Gnome specifiques. L'essentiel de la partie graphique de Gnome est en Gtk. D'ailleurs, pendant la transition Gnome 1/Gtk 1 -> Gnome 2/ Gtk 2, pas mal de widgets Gnome sont rentres de Gtk.
Il faudrait peut-etre se renseigner avant de parler.
[^] # 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.
Tout a fait. Chacun est libre de soutenir qui il veut.
La difference entre nous, c'est que d'une part, je me suis quand meme pas mal penche sur Gnome pour voir ce qu'il avait sous le capot, notamment suite aux critiques que KDE a recu. D'autre part, je me suis aussi pas mal penche sur KDE. Mon soutien a KDE n'est pas inconditionnel (ou en tout cas, pas seulement), il est fonde sur ce que j'ai vu de la facon de travailler sur le projet et de ce qu'il a sous le capot. Pour info, j'ai voulu regarder de pres, j'ai ecrit des applications Gtk, j'ai ecrit un composant bonobo pour voir, j'ai lu des listes de dev pour voir les problemes qui se posaient sous Gnome et sous KDE. Mon troll a des fondations solides.
> Votre méthode pour soutenir KDE c'est de descendre Gnome
C'est plutot que quand je vois des gens qui soutiennent Gnome, je me ressens le besoin de les informer d'une part sur les problemes de Gnome, d'autre part sur l'interet de KDE. Je le fais de facon plus ou moins objective, en avancant en tout cas des arguments que je juge valide. Et meme plus le temps passe, plus mes arguments se verifient.
Je trouve que tu manques d'arguments techniques pour contrer nos critiques. Et je pense qu'il est vraiment beaucoup plus difficile de critiquer KDE que Gnome. En general, les critiques ne depassent pas le "Qt c'est pas libre" et "Si Microsoft rachete Trolltech, KDE est dans la merde" qui sont demontees en deux phrases et deux liens.
[^] # 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.
> Y'a deux côtés dans une comunication.
Tout a fait. Cote communication, DCOP gere les deux direction pour l'IPC. Pour l'aspect graphique, KPart marche dans les deux sens. Aujourd'hui, on peut utiliser PyKDE et charger des composants KPart ecrits en C++ ou en python. Et on peut aussi utiliser KDE normal pour charger des composants KPart ecrits en C++ ou en python.
Pour ce qui est des autres langages, il ne reste qu'a ecrire le chargeur mais vraiment, ca n'est pas complique. J'ai reussi a en faire un bout alors que je n'y connaissais rien.
[^] # 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.
Les contrats Kolab et Kroupware sont tres recents, ils ont moins d'un an. Avant ca, KDE a avance sans pratiquement aucun soutien financer.
En revanche, c'est vrai que j'ai oublie l'acteur le plus influent sur KDE: Trolltech. Mine de rien, KDE doit son succes a Trolltech, grace a la qualite de Qt. Mais ca, c'etait dans le contrat de depart: Mathias Ettrich dans le post fondateur dit que Qt lui semble la meilleure bibliotheque pour lancer KDE.
Trolltech a une equipe d'ingenieurs (environ 40 personnes il me semble) qui bossent a plein temps sur Qt. Une grosse partie de leur temps est passe sur des trucs qui n'apportent rien a KDE (portage sur des vieux unix a la con, portage sous windows, integration des active X, integration des applis Motifs, XEmbed, TeamBuilder, Qt Embedded, Qt Mac, ...) mais quand mais ils permettent clairement a KDE de se concentrer uniquement sur la partie uniquement desktop.
Cote Gtk, il y a surtout Redhat et Ximian. Donc je modere mon propos.
[^] # 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.
> KDE avec Qt jusqu'à Qt 2.2 était simplement illégal
C'est fou ce que le FUD a la vie dur. Les seuls a avoir clame que Qt et KDE etait illegal sont Debian et Redhat. Pour Redhat, ca ne les a pas empeche de l'inclure dans leur distrib un an plus tard ce qui discredite quand meme pas mal leur argument.
Donc reste debian.
A cote de ca, les avocats de Suse, de Mandrake, de Trolltech se sont penches sur le probleme et ont conclu qu'il n'y en avait pas. RMS lui-meme a dit qu'il etait Ok, bien qu'il n'aimait pas trop le principe de distribution des modifications par patch.
Mais bon, si tu t'y connais mieux en licence que les avocats de trois boites majeurs de libre et que RMS, tu peux dire que KDE avait des pratiques illegales.
La seule chose qu'on peut dire objectivement, c'est que seul un tribunal aurait pu trancher la legalite de la chose.
[^] # 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.
Yeps. Et c'est plus ou moins utilise par Apple il me semble. Le principe, c'est de ne donner qu'un seul repertoire a un programme pour installer ce qu'il a besoin d'installer: ses fichiers de conf, ses extensions, ses comopsants COM, son option de demarrage automatique.
Le fait d'avoir un repertoire unique par programme fait que lorsque tu veux effacer le programme, il te suffit d'effacer le repertoire dans lequel il a installe tout ca.
Pour ce qui est de la coherence de l'ensemble, le systeme doit balayer regulierement l'ensemble de tous les repertoires de programme pour voir si de nouveaux programmes ont ete installes ou si des options de certains programmes ont ete change (info accessible par exemple avec la derniere date de modif du repertoire)
Comment fait le systeme pour retrouver ses petits apres ? Il faut que dans le repertoire du programme, il y aie une convention de nommage qui permet de savoir ce que le programme a installe.
Il faut prevoir deux vues de cette base, une vue par programme pour savoir quels sont tous les attributs d'un programme et une vue systeme qui correspond plus a la base de registre actelle: qui demarre automatiquement, quels sont les composants COM isntalles, ....
Note que pour ce genre de systeme, l'utilisation de lien symbolique comme elle existe sous Unix permet de gerer entierement ce systeme au dessus d'un systeme de fichier existant.
Au final, on obtient une sorte de base de registre avec les proprietes suivantes:
- chaque programme est bien isole et facile a effacer, analyser, ...
- on a les memes services que la base de registre actuelle.
La seule operation que pourrait faire un programme, c'est demander un nouveau repertoire a la base de registre et installer ses saloperies dedans.
Le systeme que je decris n'est pas present de base sous Linux mais un mec a commence une refonte dans ce sens et ca se passait pas mal.
[^] # 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.
On parlait de virus. Tu sais, le truc ou si tu recois un windows par defaut avec outlook par defaut, tu vas te prendre tous les virii de la terre et les renvoyer a tout le monde. Mais ca n'a rien a voir avec Microsoft.
> > Quand on pense que toutes ces machines sont infectées a cause de la nullite des logiciels Microsoft, ça fait pleurer.
> Ouais c'est vrai, heureusement Linux il est beau et il n'a jamais de failles, d'ailleurs les serveurs de Gentoo, Gnu.org, sourceforge, tuxfamily, etc... sont la pour le prouver.
Je fais une distinction entre le fait d'avoir des bugs dans un programme, ce qui est comprehensible et le fait d'avoir un checkbox dans outlook "executer automatiquement des macros" qui se traduit en francais par "je veux que mon ordinateur soit facilement et automatiquement infecte par des virus" configure par defaut.
Globalement, depuis 10 ans, la politique securite de Microsoft est un vrai scandale, alors meme que ses programmes equipent 99.99% des machines. Je pense que le terme irresponsable convient bien a cette boite. Depuis deux ou trois ans, ils essayent de redresser la barre mais c'est bien tard.
Et pour l'histoire du Tuxfamily et consort, ca n'a rien a voir dans la mesure ou c'est une attaque ciblee contre une machine precise.
[^] # 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.
Bienvenu dans le monde reel.
[^] # 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.
Il y a eu aussi enormement de problemes autour de l'internationalisation. Redhat livrant majoritairement aux americains, il s'en foutent un peu des accents et des conneries comme ca. Donc KDE sur Redhat etait en general dysfonctionnel au niveau de la gestion de l'internationalistion.
Il y a eu une epoque ou ils avaient change le fonctionnement de kppp de sorte que la doc ecrite en 47 langues n'etait plus valable. C'est la coordinatrice de la documentation qui etait contente!
On peut citer aussi le fait qu'ils ne packagent jamais les versions mineures de KDE donc les utilisateurs ne peuvent pas faire des mises a jour de correction de bug.
Et puis il y a eu les problemes quand ils ont livre un snapshot de gcc non release qui foutait la merde au niveau de la compile et de la compabilite binaire.
La suppression du 'About KDE' n'est pas tres bien passe non plus.
Pour tous ces problemes, la reponse de Red Hat a toujours ete aux developpeurs KDE a ete : allez vous faire foutre.
Donc a chaque fois que RedHat fait qqch avec KDE, on s'attend au pire meme si pour l'instant, il n'est pas arrive. Il y a eu un troll sur le fait que leur beta 9 ne contenait pas KDE qui s'est avere infonde.
[^] # 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.