Philippe F a écrit 2182 commentaires

> C'est l'avantage de bonobo. Si un composant plate, l'appli reste
> utilisable (avec une fonctionnalitée en moins).

En général, l'appli n'est pas très utilisable sans son composant. Mais pense au cas inverse, où l'appli plante mais le composant continue à tourner en arrière plan comme un malade.

Ce genre de truc est une horreur à debugger. KDE en a souffert et ca les a motivé a passer a kpart. Gnome en a souffert aussi (décolé, j'ai plus les liens mais on trouve qqs references dans les gnome foundation meeting)

Mon impression, c'est que il y a une très petite minorité de developpeurs cons ou problématiques (Neil et Mosfet par exemple) et une très grande majorité de développeurs intelligents, réfléchis, qui discutent argumentent et comme tu le dis, calme le jeu. Par exemple, j'ai un immense respect pour Waldo Bastian qui fait toujours des interventions justes.

> Par contre il y a un "troupeau" de supportaire inconditionnel qui ne veux pas prendre 3 mm de recul.

Il faut dire que Red Hat a un passé très très chargé avec KDE:
- FUD sur les premières licences de Qt
- refus de distribuer les premiers KDE
- pas de packaging des release KDE en dehors des release RedHat
- des bugs qui rendent KDE inutilisable en autre chose qu'anglais
- des modifications qui font que l'utilisateur qui suit la documentation n'arrive pas à faire fonctionner son matériel (KDE)
- un commercial qui propose un stand à KDE à une expo linux et ensuite nous envoie chier comme des malpropres.
- renommage en série de pleins de composants du Kontrol Center, ce qui les rendait potentiellement incompatible avec une appli exterieure voulant les utiliser
- suppression du 'About KDE' qui, s'il est légal, n'est certainement pas très apprécié.
- développement d'un <<faux KDE>>, c'est à dire un panel avec les icones KDE mais où aucun des programmes lancé n'est KDE.

Et plein d'autres petites broutilles. Donc à chaque fois qu'on parle de RedHat, tout le monde sur KDE se méfie. Si on pouvait éviter de packager KDE pour RedHat, je pense qu'on le ferai. Malheureusement, ils ont tout le marché d'amérique du nord. Une chose est claire en tout cas, les utilisateurs de KDE sous RedHat utilisent en général une sous-version.

Pour ce qui est des mecs de Gnome, j'ai pas beaucoup aimé l'attitude de pas mal d'entre eux au moment des flameware et autres soucis des release de Gnome. Mais je ne pourrai pas vous donner de noms.

Pour la saisie du chinois, c'est vraiment compliqué. De ce que j'ai compris, il faut quatre touches pour former un caractère. Chaque touche doit donc représenter une composante.

Je vais soulever le problème de la saisie des langues asiatiques, on verra bien si il y a des réponses.

Je pense qu'il y a des gens chez RedHat qui bossent sur Gtk que tu n'as pas compte.

Sun, leur contribution n'est pas aussi visible que celle de Ximian mais elle est fondamentale. L'ATK, c'est vraiment qqch qui permet de distinguer fortement linux et de renvoyer windows au fond du panier. Donc, s'il te plait, ne minimise pas cette contribution.

Cote Qt, Trolltech emploie 75 personnes il me semble, dont environ 60 developpeurs. Maintenant, ils ont 5 produits: Qt windows, Qt unix, Qt Mac, Qt Embedded et TeamBuilder. Plus le support, on doit arriver entre 15 et 20 personnes bossant sur Qt pour Unix.

Tiens, c'est vrai que ca fait probablement plus que Gtk.

Je suis tout fait d'accord avec toi. Je pense qu'on peut comparer le programmeur a un artisan. Il met dans un programme son savoir-faire, souvent son amour-propre et sa fierte.

On se rapproche un peu de l'art, comme tout artisan. En tout cas, on a clairement un style.

Je crois qu'il n'a plus le temps de bosser pour KDE. Il faut du packaging et basta.

Bof. J'en suis pas persuade. Tout irait plus vite si tout ce monde la bossait sur un seul projet au lieu de deux. Je ne pense pas qu'il y aurait moins d'idees.

D'un autre cote:
- le fait d'avoir deux desktop a permis de voir deux technologies differentes, c'est interessants.

- il y a des developpeurs Gnome que je ne voudrai jamais voir coder pour KDE tellement ils sont obtus.

- les bonnes idees de l'un poussent l'autre a s'ameliorer. Mais rien ne dit que avec un seul projet, ce genre de bonne idee n'arriverait pas aussi.

> > Corba a coûté très cher a Gnome en temps de développement et en
> > complexité,

> bof, toute la couche CORBA est cachée dans bonobo, la complexité
> sous-jacente n'apparaît pas quand on programme une appli bonobo

Oui, mais cacher cette complexite a pris beaucoup de temps, et c'est pour ca que bonobo est aussi peu developpe a l'heure actuelle.


> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.

Tant que t'as pas d'exemple concret, ca veut rien dire. Perso, j'ai apprecie de pouvoir comprendre comment fonctionnait kpart en lisant du code pendant une demi-heure, alors que je ne connaissais rien a KPart et aux bibliotheques partagees.

> humpf, je sais pas trop : rien ne t'empêche de définir des méthodes
> CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.

Moui, mais tout de suite, c'est plus complique. Avec un kpart, une fois que tu as remplace ton pointeur MyApplicationWidget par MyApplicationKPart, toutes les methodes a appeler restent les memes donc n'as pas plus de code a changer.

> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.

Ce n'est qu'un a priori, qui s'est revele faux dans la pratique. Le fait d'avoir un processus separe fait que tu as peu de controle quand qqch plante, et il reste des processus qui tournent en arriere plan, parfois sans que tu t'en rendes compte.

Avec un kpart (dixit David Faure, qui a bosse a la fois sur la partie Corba de KDE a l'epoque ou KDE faisait du corba et sur la parti KPart), c'est beaucoup plus franc. Ca plante, tu le vois tout de suite et tu as un core pour debugger.

Debugger un kpart est egalement plus simple parce que, quand tout est dans le meme processus, tu peux poser un breakpoint et faire tourner ton debuggeur sans souci. Avec plusieurs processus, il te faut pas mal de debuggage en parallele, pas forcement facile a mettre en place: un pour le serveur corba, un pour le composant, un pour l'hote du composant. Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.

> Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop".

De fait. Et certaines manquent pour le desktop. Combien de temps faut-il pour lancer un processus et pour charger une bibliotheque partagee a ton avis ? Qu'en est-il de l'occupation memoire ? Et je me repete mais le fait que l'api soit plus complexe a utiliser est penible.

> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.

Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops. Superieur dans l'absolu ne veut rien dire. Superieur dans le cadre d'une utilisation en desktop oui.

Tiens, ce serait interessante de compter le nombre de developpeurs payes dans chaque projet.

Je pense honnetement qu'il ya plus de developpeurs payes sur Gnome. Entre Sun, Ximian, RedHat, Suse (et oui, suse paye aussi un developpeur Gnome), ca fait vraiment du monde.

Tout le cote ATK de Gnome notamment, a du prendre beaucoup de monde pour son developpement.

Cote KDE, le seul developpeur encore paye a plein temps pour bosser sur KDE est Waldo Bastian. Il y en 4 ou 5 qui sont payes pour bosser a mi-temps (genre David Faure) et le reste c'est des benevoles. Et il y a quelques contrats, genre le serveur Kolab.

Tiens, autre question, quelqu'un a entendu parler de contrats pour developper des fonctionnalites de Gnome, comme ca c'est passe avec Kolab ?

Tiens, je voulais dire au passage que j'en ai marre qu'on crie au Troll qu'il faut tuer dans l'oeuf des qu'on parle de KDE ou de Gnome et de leurs avantages/inconvenients.

Oui, les gens ont des opinions assez forte sur KDE et Gnome. Mais si les opinions sont argumentees et constructives, je ne vois pas pourquoi on devrait se taire. Au contraire, le debat est tres enrichissant et on apprend tous des choses.

Evidemment, faut eviter de ressasser les memes arguments toutes les semaines mais une fois de temps en temps, ca fait du bien.

Tres interessant. Pourtant Qt a passe pas mal de temps a peaufiner la gestion dans langues asiatiques dans Qt3. Il me semblait que pango et Qt3 avaient exactement les memes fonctionnalites.

> le rendu de KDE en japonais est immonde

Tu pourrais m'en dire plus sur les causes ? C'est juste un probleme de police ou c'est relativement complique a expliquer ?

> une fenetre par-dessus celle ou on est en train d'ecrire. Immonde, il n'y a
> pas beaucoup de japonais qui sont motives pour utiliser ca.

C'est ce que ma copine utilise pour taper du chinois sous windows et elle trouve ca normal :-) . Mais je crois que le chinois reste plus complique que le japonais de ce point de vue la. J'ai meme pas essaye de la passer sous linux encore, j'ai peur.

Est-ce que t'as des liens techniques a me fournir sur le sujet, ca m'interesse vraiment. Je savais que Gnome etait en avance au niveau accessilite mais vraiment, je croiyais que pour les langues asiatiques, KDE ou Gnome c'etait pareil.

Cettte histoire de gtk-im, je me demande d'ailleurs si c'est pas lie a l'accessibilite. En effet, atk necessite de changer de methode pour rentrer des caracteres.

Je vais me renseigner pour voir ce qu'on peut faire cote KDE. Evidemment, tout ce qu'il manque c'est un mec motive pour coder tout ca.

> Et j'ai trouve d'autres avantages a Gnome.

Je n'en doute pas. Contrairement a ce qu'on pense, je ne crache pas sur Gnome (sauf quand je l'utilise, c'est trop dur de travailler dans un environnement ou on est pas a l'aise ) et je pense qu'il peut fournir une bonne solution desktop et il y a de tres bonnes applications qui manquent sous KDE.

Mais les composants graphiques et la scriptabilite font partie des raisons pour lesquelles tout le monde a dit pendant la transition KDE1 / KDE2 que KDE c'etait de la merde parce qu'il n'utilisait pas Corba, que jamais ou qu'avoir un composant sous KDE serait super difficile alors que Corba allait trivialiser tout ca, avec du remote scripting et bla bla.

Donc j'aime a rappeler que sur ces plans, Gnome est vraiment (pour l'instant) un echec. C'est d'autant plus ironique que MDI croit a fond au principe des composants graphiques.

> les zealots de KDE disent ca depuis que Gnome existe et ca n'a jamais
> decourage ni les developpeurs ni les utilisateurs de Gnome

Tel n'est pas mon but. Je prefere juste souligner les differences techniques entre les deux. Je pense vraiment que KDE a fait des meilleurs choix techniques qui payent beaucoup sur le long terme.

L'utilisation d'un desktop ou d'un autre depend de beaucoup de facteurs emotionnels et subjectifs. Il y en a tres peu d'objectifs. Le hasard joue beaucoup aussi. Par exemple un jour, tu as cherche la fonctionnalite glorb et tu ne l'as pas trouve sur le desktop X donc tu es passe au desktop Y ou elle etait plus accessible et apres, tu vas cracher sur X parce qu'il n'a pas glorb alors qu'il l'a a un endroit different. Vous pouvez remplacer X et Y par Gnome ou KDE au choix. Il suffit de lire une thread slashdot pour voir plein de gens dans ce cas la :-)

Desole pour les repetitions. Quand on ecrit un truc long, on s'y perd un peu.

Je ferai un autre journal sur les autres elements en effet, ca promet d'etre interessant. Par exemple il y a eu pas mal de FUD sur KDE, repandu par la communaute du logiciel libre.

> Ça casse du Gnome puis ça fait de la pub KDE.
> J'aime bien ce type de commentaire car l'auteur est "démasqué".

J'exprime mon opinion sur Gnome et KDE. Mon dieu, je suis démasqué, j'ai une opinion! T'es vraiment trop fort!

As-tu remarqué avec ta perspicacité que je fournis des arguments pour supporter mon opinion ? Ca fait une grosse différence avec ton post qui est complètement vide, genre je parle pour me rendre intéressant mais j'ai rien à dire.

> J'espère pour toi que t'y vois pas Gnome ça pourrait te rendre malade.

Si j'y vois Gnome et non, ca ne me rend pas malade car je vois aussi que Gnome a quelques années lumières de retard sur KDE et que c'est pas près de changer. Le seul point sur lequel Gnome assure, c'est sur l'accessibilité.

> Gnome assure une communication (et de qualité). Trop peu d'applications Gnome l'utilisent.

T'es tu demandé pourquoi ? Il y a une raison. C'est que mettre un composant bonobo en place, c'est pas aussi simple et léger que mettre un kpart en place. Dans ma vision personelle, je pousserai même jusqu'à dire que programmer une application en gtk/gnome demande un investissement significatif en temps, et que des lors, il ne reste plus beaucoup de temps au programmeur pour faire des petits trucs en plus. Ces petits trucs pouvant être de respecter correctement les HIG ou rendre son application disponible sous forme de composant. Mais laissons cet aspect controversé de côté et regardons des éléments objectifs.

Je pense que le succès plus important des composants dans KDE est lié aux points suivants:
- kpart existe depuis plusieurs années dans KDE
- c'est bien documenté et très léger à mettre en place pour un développeur
quelques références:
http://phil.freehackers.org/kde/kpart-techno/kpart-techno.html(...)
http://developer.kde.org/documentation/library/3.1-api/kparts/html/(...)
http://developer.kde.org/documentation/tutorials/index.html(...)

à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes. J'en avais cherchées il y a deux ans et un an et je n'avais presque rien trouvé. Depuis Michael Meeks a pondu quelques bonnes documentations.

- bonobo n'est arrivé à maturité que récemment
- très peu d'applications sont bonobo-aware.
- comme beaucoup d'applications utilisent déja des kpart, il est facile de trouver des exemples sous KDE. L'effet inverse joue sur Gnome

Donc en gros, il semble que la différence provienne de la maturité tardive de bonobo. Comment se fait-il que bonobo arrive à maturité aussi tard alors même que les composants faisaient partie de la vision de base d'un bureau développé par MDI (cf sa page web, vision très intéressante et qu'on peut voir réalisée aujourd'hui ... dans KDE!). Au départ, Gnome n'a qu'un an de retard sur KDE mais en terme de composants, on est a peine dans Gnome au niveau qu'on avait dans KDE 2.0

Je suis intimement persuadé que la raison de ceci est que les technologies KDE pourtant très largement critiquée en leur temps sont bien plus adaptées au problème. Le fait du partir sur du Corba a coûté très cher a Gnome en temps de développement et un complexité, pour un résultat qui n'apporte rien de plus que kpart, ou bien des choses qui ne servent à rien. Par exemple, j'aime bien cette phrase dans le tutorial de bonobo: "Finally, using a component model allows the running of your controls on other machines. There must be someone, somewhere who wants that."

D'un point de vue développeur, ce que je vois comme inconvénient à bonobo:
- peu d'applications l'utilise donc c'est dur de trouver des exemples
- l'échange d'informations par property bag est lourd à mettre en place.. Cela veut dire que le développeur Gnome doit modifier pas mal son code pour gérer la communication avec le composant bonobo. KPart de son côté remplace un appel de méthode par un appel de méthode. Et dehors du type des pointeurs qui change, migrer du code vers kpart est très rapide
- s'il y a un probleme avec bonobo, il faut descendre dans les couches basses et ça devient tout de suite très compliqué: c'est du corba. La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.

> Je n'ai jamais vu une KPart s'écrire toute seule.

Il faut moins de 50 lignes de code pour passer une application en KPart. C'est vraiment proche du "ça s'ecrit tout seul"


> rien de tel n'existe sous Gnome Office et donc le mot integration est tres tres exagere.
> Probablement exact, mais je ne vois pas en quoi ça rend KDE meilleur (juste KOffice).

Le point important, c'est que les technologies KDE sont plus avancées et permettent de faire ce genre de chose beaucoup plus facilement. Et, c'est grâce aux technologies mises très tôt en place dans KDE, sur lesquelles KOffice ne fait que s'appuyer.

> Vous n'avez pas montré que KDE était supérieur à Gnome, juste que KOffice est meilleur que Gnome Office pour certaines raisons

Ce que je veux montrer, ce n'est pas que KOffice est supérieur à Gnome Office, c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome.

On a parlé composant mais si on parle de scriptabilité, Gnome est carrément à des années lumières de retard.

Imaginons par exemple que je veux ouvrir une konsole avec trois sessions ssh vers trois différentes machines avec un script:

# launch konsole with remote dcop control enabled
konsole --script &
# process-id is used to generate the dcop name of konsole
kid=konsole-$!
echo Konsole is $kid
session="session-1"
# you need to add a small delay
sleep 0.5

dcop $kid $session sendSession "ssh machine1"
sleep 0.5

# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine2"
sleep 0.5

# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine3"

J'aimerai voir la version équivalente de ce script pour Gnome. Notons que ce genre de chose est possible depuis KDE 2.0 . Pour en savoir plus:

http://developer.kde.org/documentation/tutorials/automation/index.h(...)





> Cette affirmation serait-elle donc un troll grossier ?

Non, c'est une opinion que je suis en mesure d'argumenter.

<<
Dans le cadre du projet Gnome, les applications n'ont pas à "s'intégrer entre elles". Si Gnome est bien foutu et que les applications sont bien intégrées au technologie Gnome alors elles seront utilisables ensembles.
>>

Certes, elles seront utilisable de facon similaire car basees sur les memes technologies (Gnome Desktop).

Mais elles ne pourront pas s'integrer entre elles (avoir une feille de calcul GnuSpread dans un rapport tape avec AbiWord). L'integration inter-application n'arrive pas par magie, il faut la penser et travailler beaucoup dessus pour qu'elle soit utilisable.

En dehors du minesweeper dans GnuSpread, je n'ai jamais vu d'integration digne de ce nom dans Gnome Office.

<<
C'est Gnome qui doit assurer la communication entre les applis et pas les applis qui doivent se "causer" directement. Du moins idéalement.
>>

Gnome doit assurer la communication _et_ les applis doivent se causer entre elles. Sinon, c'est juste des applications Gnome.

Soue KDE, les applications de KOffice, sont en general plus que des applications KDE, elles s'integrent entre elles.

Il y a deja les bibliotheques kpart pour faire de l'integration d'application. Mais dans le cadre de KOffice, ca ne suffit pas car une suite office a besoin de plus de notions pour faire une integration propre (documents/vue, chargement/conversion/sauvegarde, ...). C'est pourquoi il existe de kopart, qui sont des composants koffice.

A ma connaissance et corrige-moi si je me trompe, rien de tel n'existe sous Gnome Office et donc le mot integration est tres tres exagere.

KDE: a look into the future

C'est qui Pen of Chaos ?

Tu la sors d'ou ton option -i ? Ca n'existe pas sur ma mandrake, avec un sed 3.02 .

Genial! Du coup, le packaging prend trois semaines de plus, ca c'est une feature (et oui, c'est plus facile de packager 15 paquets que 85) et toute installation leve des milliers de dependances.

Et avoir konqueror sans khtml, j'avoue que j'en revais. Je suis heureux que ce soit possible avec debian.

Sans deconner, aujourd'hui ou la place sur un disque dur ne coute rien, je vois pas trop l'interet d'economiser quelques ko d'applications, a cote de tous les resources que ca bouffer pour en arriver la.

J'aime bien la phrase "selon lui, seul les clients finaux doivent faire le choix de leur OS".

On va plutot prendre des clients finaux completement ignares en informatique, non conscients des consequences sur le long terme d'une quelconque solution (genre des scecretaires) et on va leur demander de choisir entre le truc qu'elles utilisent depuis 20 ans et linux, le machin des informaticiens.

> M'enfin si il y a quelques personnes motivees.... j'apprendrais ptetre a coder en gtk !

Entre nous, je te le deconseil. Le C est tres peu adapte au codage d'une interface graphique, ce qui fait que gtk est beaucoup plus chiant a coder que Qt ou KDE.

Pour faire un truc pareil, mieux vaut utiliser un langage plus objet comme python (PyQt, PyKDE ou PyGtk) ou du C++. Mais le C objet, c'est vraiment une aberration qui coute cher en temps de developpement.

Les changements que j'aime bien:

- vimpart est maintenant integre dans KDE, donc on peut utiliser vim al 'intererieur de KDevelop, ou en tant que viewer dans Konqueror. Pour l'avoir dans kmail ou kate, il faut envoyer des wishlist aux auteurs respectifs

- des nouvelles applications pour faciliter l'acces aux handicapes pour le desktop: KMouth (aide a former des phrases), KMag (loupe), kttsd (synthetiseur vocal, marche avec konqueror et Kate), KMouseTool (clique la souris a la place de l'utilisateur, pour ceux qui ont le carpal tunnel)

- meilleure integration avec les portables (KLaptop)

Et plein d'autres, regarder la section "finished":

http://developer.kde.org/development-versions/kde-3.2-features.html(...)

J'ai vu qq'un dans les forum de gentoo porter gentoo pour icc. Je ne me rappelle pas si il a vu un gain de performance net mais en tout cas, ca a deja ete fait.

En ce qui me concerne CVS avec un cron tous les jours (ou un script pour forcer la m-a-j) me suffit. Quels sont les avantages de weex ou sitecopy par rapport a cette solution ?

Qu'en est-il des autres moteurs majeurs justement ? Jamais je ne ferai confiance a msn ou aol pour acceder a une quelconque de mes informations personelles.

Au contraire, google a montre de nombreuse fois une bonne comprehension et un respect du fonctionnement du web et des internautes. C'est le premiere moteur qui ne te bombardait pas de publicite a tout va alors qu'on etait encore au temps du max de pub == max de fric. Imaginez comment il a du etre difficile de defendre face a des investisseurs, au moment de la montee puis de la chute des .com le fait que le moteur fonctionnerait sans publicite pendant plusieurs annees, puis que les publicites ne seraient que de tout petit format et pas du tout intrusive ? Je suis sur que les auteurs ont du se battre pour ne pas devoir mettre de banniere ni de popup.

Ca, et leur humour DMCA (on vous montre pas le lien mais voila ou vous pouvez aller le chercher) me fait dire que ce sont des gens bien.

Je respecte pour ceux qui ont developpe et google et leur cookie ne me gene pas, je leur donne avec plaisir, a cote de ceux qui essaye de me voler des informations personnelles en regard d'un service inexistant.

Oui des derives sont possibles parce que en effet, google a beaucoup de pouvoir. Mais pour l'instant, ils me semblent avoir conserve leur ethique et je continue a leur faire confiance.

<< Cette recherche de la perfection est hors de portée des éditeurs de solutions propriétaires car il est impossible d'imaginer dans un laboratoire les sévices que des milliers de personnes sur des machines toutes différentes vont faire subir au logiciel. >>

Je trouve cette remarque tres interessante. Le dynamisme d'OpenOffice est aussi tres difficile a reproduire dans un milieu proprietaire puisqu'il ne genere pas un centime. Sun fait un investissement qui a pour but de preparer la sortie du tout-microsoft. C'est un invistissement sur du long-terme. A court terme, OpenOffice est a mon avis un trou fiancicier. On paye des developpeurs pour faire marcher un produit le plus possible comme celui du concurrent, et on donne le resultat a tout le monde.

Voila pourquoi peu de boites faisant du proprio peuvent faire comme OpenOffice. En general, les trou financiers ne sont pas bien vus.

A cote, si on prend KOffice: entre un et deux developpeurs payes a plein temps et le reste que par des benevoles. Le resultat est franchement impressionnant, surtout si on considere que KOffice est parti de rien, alors que OpenOffice avait deja un gros passe avec StarOffice.

Tout ca pour dire que a la vitesse ou se developpe KOffice et KDE, je crois qu'il va depasser pas mal de projets dans quelques annees.