> 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.
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
[^] # 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.
[^] # 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