> Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire.
Non. Les quelques constructeurs hyper motives qui veulent sortir des drivers pour Linux y arrivent tant bien que mal apres beaucoup d'efforts.
Imagine une boite qui fait un peripherique a la con. 95% de son marche est sous windows, 5% sous Linux (je suis tres optimiste, normalement, c'est 99.99999% ). Elle passe 2 ans a developper son driver avec son equipe de 2 personnes et il marche sous tous les windows. Elle est contente.
Mainenant, cette boite n'a aucun a priori sur Linux. Elle se dit que ca pourrait etre sympa de recuperer les 5% restant. De toute facon, sa version windows ne lui coute en maintenance que quelques jours-hommes par an donc elle a un tout petit peu de temps libre.
Voila qu'elle decouvre que si elle veut faire des drivers pour Linux, il faut qu'elle les fasse pour une version de Linux donnee. Ensuite, il faut qq'un qui suive en permanence l'evolution du kernel pour garantir que le driver n'est pas pete a chaque seconde qui passe. Sa maintenance va se chiffrer en mois-hommes parce que tout Linus a decide que l'api utilisee par le driver etait de toute facon pourrie et obsolete et va donc re-ecrire un truc completement incompable.
On imagine que la boite suit cette premiere transition. Apres, bien que le truc ait ete re-ecrit, il y encore des modifs a apporter a l'API du machin qui sont faites tranquillement, sans communiquer plus que un message sur la lkml, et qui petent le driver de nouveau.
Pour resumer, en terme de cout, un driver sous Linux, c'est quelque mois-hommes par an alors que le marche lui-meme est beaucoup plus faible que sous windows.
Le choix est vite fait pour n'importe quelle entreprise, il n'y aura pas de driver pour Linux. Mais ca Linus s'en fout apparemment.
> Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a
> pas dans le code du driver des hacks qui créeront des
> incompatibilitées avec des versions futures à cause de changement
> internes au noyau
Oui, mais dans ce cas, tu peux faire un report de bug clair incriminant le driver. Maintenant, la situation, ce sera "ca marche pas" sans que tu saches si un truc subtil a change dans le noyau, dans le driver, si le driver est code comme un pied ou si tu as un probleme sur ta machine.
Personellement, je considere ce modele de developpement comme une regression. Certe Linus aura moins de difficulte. Par contre, ca va etre la merde pour tout le monde en dehors de ceux qui suivent la lkml.
Les noyaux vont etre beaucoup moins testes par les utilisateurs puisqu'une mise a jour deviendra une operation tres dangereuse si on n'est pas sur de maitriser.
De tres gros projets arrivent tres bien a gerer l'evolution d'une base de code stable avec une evolution rapide (Mozilla, KDE, Gnome, Qt, Gtk) tout en conservant la compabilite binaire. Je ne vois pas pourquoi le noyau n'y arriverait pas. En fait, si , je vois tres bien. C'est parce que ca ne plait pas a Linus. C'est pas assez fun, c'est bien plus fun de tout peter a tout moment parce que ca nous plait que de conserver des API mouvante parce que soi-disant, ca va ameliorer la qualite des drivers.
Plus ca va, plus Linus fout la merde dans Linux. Mais c'est son bebe, on n'a rien a dire.
La phase "mais non, c'est pas dur de recompiler son noyau" ne pourra plus etre valable du tout.
Ca m'enerve vraiment. Quand je vois tous les efforts deployes par Trolltech, KDE ou Gnome pour qu'une mise a jour incompatible des lib se passe le plus tranquillement possible du monde, j'admire. Ils ne font ca que tous les 2 a 4 ans, ils preparent de bibliotheques de compabilite, ils preparent les developpeurs pendant plusieurs mois en faisant des snapshots, ils communiques, ils reflechissent longtemp a l'avance a ce qu'ils vont changer.
Linus, lui s'en bat tout simplement les couilles et je trouve ca dommage. Il a toujours eu cette attitude mais la ca devient vraiment genant. Le 2.6 ne pourra plus etre considere comme un noyau de reference.
Qu'est ce qui te permet de faire cette prediction optimiste ?
Le probleme souleve est au coeur du fonctionnement de XUL. A premiere vue, le spoofer fait exactement ce pour quoi XUL a ete prevu. Donc la facon la plus simple de remedier au probleme, c'est de supprimer l'execution XUL. Ah ouai, mais ca risque de serieuseement diminuer les possiblites du browser.
Bref, avant de predire, j'attends de vois ce que va proposer la communaute mozilla.
Tout a fait. emerge, c'est d'un ennuyeux comme nom. Alors que jeter un sort, ca jette plus niveau vocabulaire. Et dans l'imaginaire, c'est un peu ca, quand on lance un emerge/apt-get, il y a un peu de magie qui s'execute pour nous rapporter tout ce qu'on vuet.
J'ai pas dit qu'il avait ete seul. Mais tout ce qui est modele de composant et virtual file system sont des choses dont MDI parlait deja au temps de Gnome 0.x, avant meme qu'elles ne soient realisees concretement. Je ne serai pas surpris qu'il aie eu aussi la vision d'un moteur dynamique de coeur de Gnome, comme celui qui va etre utilise pour generer les differents bindings de Gnome. Il avait plein de bonnes idees MDI, dont un certain nombre ont abouti a qqch de pas trop mal.
Non, j'avoue avoir beaucoup de mal a te suivre dans tes raisonnements. Si plutot que de faire du delire, tu t'exprimais en phrases claires argumentees en parlant de faits reels ou au moins en proposant des explications qui se tiennent logiquement et socialement, ca serait plus facile de discuter avec toi.
> > C'est juste que dire que Ximian est completement independant de
> > Gnome et vice versa, ce n'est pas tout a fait vrai.
>
> Et tu veux en venir où ?
Je veux en venir au fait que quand tu dis que MDI est completement independant de Gnome, ce n'est pas vrai. MDI a encore via Ximian et via d'autre manieres une certaine influence sur le projet Gnome, bien qu'il n'en soit plus le leader ni meme un contributeur.
Et le fait que MDI bosse sur Mono encourage la communaute Gnome a reflechir autour de Mono. Ce n'est pas negatif mais c'est indeniable.
Et pour revenir a mon argumentation originelle (car perso, je tiens ma ligne de raisonnement), les differentes declarations de MDI ont enerve ou decu au cours du temps un certains nombre de membres de la communaute Gnome (car tout le monde dans Gnome ne voue pas une admiration sans borne a MDI et ses methodes). La direction actuelle de Gnome a largement ete insuflee par MDI et elle est differente de ce dont il faisait la promotion au moment de Gnome 1.0 et meme avant.
Donc il y a un certain nombre de mecontents chez Gnome qui se retrouveront probablement dans ce fork. Non, a peu d'exceptions pres, ils n'iront pas vers KDE car ils aiment bien le framework Gnome et ce qu'ils en ont fait. En revanche, ils ne sont pas necessairement en accord avec la direction pro-entreprise, pro-simplification qui (mais je me repete) etait loin de faire partie de Gnome dans sa version initiale. A l'epoque, c'etait meme Gnome le bureau de hacker hyper configurable et KDE le bureau pour les neuneu venant du monde windows.
En fait, il y a en effet deux categories d'utilisateurs. Ceux qui ne customisent rien, et ceux qui veulent un bureau exactement selon leurs specs.
Pour les seconds, Gnome a choisi de cacher pour pas que les premiers tombent dessus. KDE a fait le choix de les considerer comme des utilisateurs legitimes et de leur donner aussi une belle interface graphique.
> Ça fait depuis 3 ans que MDI ne fait rien pour Gnome !
> C'est claire.
Ca ce n'est pas vrai. Il n'a pas ecrit de code pour Gnome mais il contribue au projet autrement. Il pousse le desktop dans les entreprises, il developpe evolution pour que Gnome puisse etre accepte en entreprise.
Il continue aussi a avoir son role de visionnaire. Quand il voit une bonne techno et qu'il pond un article en disant a quelle point elle est interessante, tous les hackers de Gnome regardent ce qu'il dit. Et ca n'a rien de negatif. MDI est un hacker de Gnome respecte pour sa contribution par les autres hackers de Gnome, donc quand il dit qqch, les autres l'ecoute.
Bref, nier qu'il y a encore des liens entre MDI et Gnome me parait un peu extreme comme attitude. Cependant, c'est sur qu'il n'est pas a la direction de Gnome et qu'il repete toutes les jours que Gnome ne sera pas developpe en mono. A ton avis, pourquoi il a besoin de le repeter autant ? Serait-ce parce que en raison de son role historique dans Gnome, des gens s'imaginent le contraire ?
Comme tu peux faire ces deux choses sans passer par le centre de controle, l'ergonomie de celui-ci est un tout petit peu moins importante.
Perso, dans le centre de controle KDE, comme il est complique, j'utilise tout le temps la fonction recherche. Je trouve tout ce que je veux du premier coup.
Je ne sais pas pourquoi tu sors ton delire sur Red hat.
Ce que te dis le monsieur, c'est que pendant quelques temps, la page de download officielle de Gnome etait chez Ximian. Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien), justement pour montrer que Gnome est bien independant dans la mesure du possible de Ximian et eviter les polemiques "Ximian controle gnome etc"
Exhiber la page de download actuelle et sortir ton delire sur Redhat ne change rien au fait que ce dont on parle est arrive.
Pour eviter toute surinterpretation, ce n'est pas mal que Ximian aie des liens forts avec Gnome. Ils contribuent avec evolution et les developpeurs de Ximian sont de tres gros contributeurs de Gnome et sont tres respectes.
C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
Ca c'est la theorie. La pratique est beaucoup moins claire. Par exemple, on m'a cite le cas d'application d'une technique a un autre domaine que son domaine d'origine. Il y aurait innovation parce que c'est nouveau dans ce domaine bien qu'en soi, il n'ya rien de neuf, juste du recyclage.
Exemple auquel j'ai ete confronte : transposition dans le monde de le carte a puce d'une technique logicielle a la con utilise couramment dans les appli non embarquee.
>> Mais je pense que les dev. bonobo sont un peu responsables
Et non, ce ne sont pas eux les responsables. Au contraire, ils ont fait un travail formidable dont l'ampleur est probablement mal appreciee.
Les responsables, ce sont qui ont affirme haut et fort que Corba etait parfaitement adapte comme modele de composant pour un desktop et ont continue sur ce choix technique. Ils ont fait fi de l'experience de KDE qui a renonce a CORBA a bout de deux ans de galere et ecrit un remplacant en moins d'un mois.
Corba est une tres bonne techno, mais c'est trop lourd par rapport aux besoins d'une techno de composant desktop. Donc il y a eu un travail enorme qui a ete fait pour rendre CORBA accessible relativement simplement en C. Du coup les developpeurs sont tellement pris dans Corba que documenter l'interface bonobo relativement triviale, ca leur parait superflu (ce dernier point est ma petite interpretation).
A cote, KDE est parti d'une techno existante et l'a a peine modifie pour en faire une techno de communication qui convenait parfaitement.
Et ce choix technique de CORBA, MDI en est en partie responsable. Comme il est responsable de pas mal d'autres choses chez Gnome, en bien comme en mal.
Non, je ne vois pas ca comme une insulte mais ca m'agace profondement oui.
> que le but des développeurs de KDE, c'est de faire une interface de qualité qui ne soit pas déroutante pour les utilisateurs qui viennent de Windows
C'est la qu'il y a un probleme. Le but de KDE est de faire une interface conviviale pour tous les utilisateurs. Cela inclut les utilisateurs de windows, de MacOS, de Gnome, de Mozilla, ...
Quand les devs font des choix d'ergonomie, ils essayent de prendre tous ces parametres en compte, en soupoudrant ca de bon sens et de connaissances en ergonomie.
C'est pour ca que je trouve ca tres reducteur de dire qu'on ne vise que les utilisateurs de Windows, et que ca ignore tout le travail de fond fait par certains developpeurs (Waldo Bastian, Aaron Seigo)
Par exemple le simple-clic par defaut (dont personellement j'ai horreur) a ete choisi en raison de l'influence plus faible sur la degradation physiologique de la main.
L'ordre des bouton, c'est pour moi un debat ininteressant au possible.
L'explorateur de fichier sous KDE, je le trouve trop complique personellement. Beaucoup trop de menus, mal organises. D'un autre cote, il a des bons cotes et il est defendu comme un bon outil.
Pour le centre de controle, c'est pas facile de l'ameliorer sans trop bousculer les habiltudes des utilisateurs, et gardant toutes les options mais en conservant l'ergonomie.
Pour ce qui est du menu K, je ne vois pas ce que tu veux dire. Je regarde des screenshots du menu Gnome et je vois pas en quoi il ne ressemblerait pas a celui de windows, ou en quoi celui de windows ressemblerait plus a celui de KDE (pour anecdote, sous windows, j'ai reorganise mon menu demarrer "a la KDE" ou "a la linux" avec des applis internet, systeme, graphique et multimedia)
Oui, pour le menu, on etait encore dans la metaphore.
> (mon dieu, on ne peut pas défendre Gnome sans insulter KDE pour toi ?)
Non, je me posais la question en toute sincerite. J'ai l'impression qu'on parle beaucoup de l'ergonomie de Gnome, de HIG mais qu'on n'en parle tres peu pour KDE. J'arrive pas a determiner si c'est parce que les gens n'utilisent pas KDE du tout, pensent que KDE s'en fout completement ou sont satisfaits de KDE et donc n'envisagent pas de discuter ce point. Ou bien il existe peut-etre encore une autre explicatoin que je n'entrevois pas.
En fait, en y reflechissant, je vois une explication: KDE a la meme ligne de conduite et le meme HIG depuis 5 ans. Cote Gnome, ca genere des remarques puisqu'il y a eu un changement de strategie, d'un cote avec le choix d'exclure des options de config, de l'autre avec la publication du premier HIG, et enfin avec l'introduction de gconf.
<< une carte détaillée avec beaucoup plus de plats (gconf-editor). >>
Beaucoup plus de plats oui, mais j'ai pas eu l'impression que gconf-editor soit detaille. Il y a des explications pour les options ? De la doc.
L'avantage au moins du control center, c'est que les options sont clairement documentees et organisees.
<< un menu par défaut soigneusement étudié. >>
Juste une question comme ca : vous pensez que le menu de KDE n'est pas soigneusement etudie ? Le choix des defauts fait l'enjeu d'autant de d'attention qu'il le fait sur Gnome. Meme si les choix finaux sont differents, ils sont reflechis et portent une justification.
C'est quoi les "autres environnements plus proches de windows" ? Ca comprenait KDE ?
Sinon, il y a des etudes qui montrent aussi que les gens s'adaptent tres bien a KDE.
Moi ca m'agace un peu ce "KDE ressemble a windows, Gnome ressemble plus au mac."
Si tu prends une demi-heure, tu peux faire ressemble KDE bien plus a un mac que Gnome. Barre des menu en haut, look aqua, ...
En fait, c'est un probleme de referentiel. Je trouve pas que KDE ressemble a windows mais ce qui est sur, c'est que dans l'esprit et dans le choix de couleurs ou dans l'organisation, on va retrouver des choses qu'on trouve aussi chez windows.
C'est quoi pour vous le fait que KDE ressemble a windows ?
Apres un coup d'oeil a differents screenshots, j'ai trouve: c'est le style des icones et le style Qt qui font que KDE ressemble a windows. Gtk a des widgets qui n'ont pas la meme taille ni la meme organisation que Qt. KDE en a qui ressemblent plus a ceux de windows. Ca combine au look'n feel des icones, ca fait qu'on se sent ailleurs quand on est sous Gnome.
L'objet des applis d'un bureau, c'est d'etre integrees. Ca vaut meme pour un terminal. Si tu veux que le beep du terminal soit gere correctement,il te faut te lier avec le gestionnaire de son. Si tu veux savoir si le beep doit etre visuel ou pas, il y a priori un setting global su r le desktop qui precise si le beep doit etre visuel ou pas, et qui y associe un son que tu peux customiser.
En fait, tu veux une appli Gnome sans Gnome. Le but d'un desktop tel que Gnome etant au depart de fournir un ensemble d'applicaitons coherentes et integrees, il n'y a pas de raisons de rendre ce genre de dependance soit optionelle. Cela dit, tu peux patcher.
Si tu retires les dependances a Gnome, ca ne sera plus Gnome-terminal mais tu auras une application prete pour etre integree dans XFCE....
Tes besoins et ta philosophie correspondent plus a XFCE qu'a Gnome.
Sinon, a titre de curiosite, c'est quoi la killer feature de Gnome terminal qui fait qu'il t'es si indispensable ? A chaque fois que j'ai essaye Gnome, c'est justement Gnome-terminal qui m'a fait le plus souffrir a cause de ses limitations par rapport a konsole (il s'agissait de Gnome 1.4) donc je suis plutot curieux.
Le fond du probleme, ce n'est pas que les fichiers de conf soient en xml ou pas.
Si tu lis le debut du site web du mec, il resume tout dans une seule phrase: Gnome commence a utiliser des technologies qui l'effraient. Avant, il controlait tout: le C, gtk, les fichiers de config editables a la main, ... Maintenant, il y a beaucoup d'autres technologies, de programmation, de composant, de stockage des donnees et il n'aime pas parce qu'il n'a plus le controle absolu.
Vu son projet, il ferait mieux de se tourner vers des bureaux alternatifs type XFCE qui restent a mon avis dans sa philosophiie, plutot que de forker Gnome qui est parti dans une autre direction.
C'est parce que certains documents ne sont pas des fichiers. Une page html, pour une utilisateur, ce n'est pas vraiment un fichier. On peut penser egalement aux documents composes de plusieurs fichiers qui posent probleme.
Donc un nom plus generique et plus correct a ete choisi.
Pour le nombre important de fichiers lus, il s'agit du cas ou tu lances ton bureau. Il faut activer un certain nombre de services (dans le cas KDE: kwin, kicker, ksycoca=surveillance des fichiers de config, kdesktop, kdcop, splash screen), chacun avec son fichier de conf et restaurer toutes les applications de ta session precedente. Tout le temps gagne a ce moment la te donnera une tres grande satisfaction des utilisateurs en terme de "desktop X se lance vachement vite quand je me logge".
> Le configuration est lu une fois au début et c'est tout.
Non. D'une part, le simple fait de lire la configuration peut-etre une operation complexe. Typiquement sous KDE, tu as un setting system dans $KDEDIR/config/myapp/myapp.rc que tu peux surcharger avec un setting utilisateur $HOME/.kde/config/myapp/myapp.rc
Tu peux rajouter d'autres repertoires contenant des settings (suffit de les rajouter a $KDEDIRS) pour surcharger les settings systemes avant d'arriver aux settings utilisateurs.
Pour une application donnee, il se peut aussi que les settings soient repartis dans plusieurs fichiers de config. C'est notamment le cas quand tu vas utiliser un composant kpart. Par exemple kontact (l'equivalent d'evolution) va lire des setting kontact, des settings kmail et va lire aussi ta liste de contacts et no de telephones qui se situera ailleurs.
La configuration est aussi susceptible d'etre relue. Typiquement, quand tu fais 'appliquer' sur un panneau de config, tous les applications utilisant ce jeu de parametres sont notifiees qu'il a evolue et qu'il faut donc le relire.
Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Je me souviens que pour KDE 2, Waldo Bastian avait fait une grosse passe la-dessus et avait trouve par exemple que il est plus rapide de lire un fichier texte tout d'un coup plutot que ligne par ligne, et que il ne faut faire la conversion unicode que si on a besoin d'une chaine traduite. Ce genre d'optimisation avait permis de gagner quelques dizaines de secondes par ci par la, et en tout, c'est plusieurs secondes d'economisees.
En terme de temps de demarrage, tout est a prendre parce que l'utilisateur appreciera beaucoup.
Il se trouve que dans le cas d'un desktop, ce temps _est_ genant pour de nombreuses raison que j'ai la flemme d'expliciter ici. Rien qu'en occupation cpu, parser du xml pose plus de problemes que lire un fichier texte. Ajoute ca a l'utilisation memoire et a d'autres parametres, le temps devient loin d'etre negligeable.
XML n'est pas la panacee. C'est tres adapte pour faire des representations de donnees complexe, mais un bon fichier texte comme on en utilise depuis les annees 70 garde encore beaucoup beaucoup d'avantages.
La reponse a tes deux dernieres question est en effet que la vitesse d'un desktop est tres subjective. Un utilisateur de base va mesurer la vitesse d'une application en terme de feedback visuel. Une appli qui met 1.5s a faire qqch, mais avec un feedback visual aux temps 0.3 1 et 1.5 paraitra rapide. Une appli qui met 1s a executer la meme action avec un feedback visuel uniquement au bout de 1 s semblera plus lente.
C'est pour ca que dans toute appli graphique et notamment dans KDE, il y a pleins de hacks pour fournir au plus vite un feedback visuel et retarder au maximum les operations qui prennent de temps, de facon a les faire en arriere plan, quand l'utilisateur voit deja qqch.
Je suis tout a fait d'accord. Ce fork ne semble avoir aucun fondement technique valide mais rassemble toute la mauvaise humeur accumulee sur Gnome depuis quelques annees par un certain nombre de developpeurs et d'utilisateurs.
Le texte ressemble vraiment a du "on va faire Gnome comme KDE" et de ce point de vue la est assez marrant.
Je pense que le probleme de Gnome, c'est de ne pas avoir garde un message directeur et une vision d'ensemble coherente depuis ses debuts.
Si tu regardes KDE, ils sont encore exactement dans la lignee du post de Mathias Ettrich du 1998.
Au contraire, les leaders de Gnome, et notamment MDI ont fait passer plusieurs messages differents au cours des annees, avec une attitude assez demagogue. A chacun de ces messages differents, un groupe different s'est rattache a Gnome. Aujourd'hui, ces differents groupes sont decus parce que Gnome n'est pas ce qu'on leur avait promis a l'epoque d'ou cette accumulation de mauvaise humeur et cette envie de retourner au temps de Gnome 1.0
Pour expliciter un peu plus la partie messages directeurs de Gnome:
[fondation de Gnome] KDE ca pue, c'est fait avec Qt qui est pas libre : ca c'etait le message initial. On va faire un bureau vraiment libre, d'ou rapprochement avec la FSF.
Ceux-la (et RMS en fait partie) sont decu par les dernieres orientations de MDI vers Mono sous licence Mit et par l'orientation resolument tres commerciale de Ximian
[fondation de Gnome] Qt, ca pue c'est du C++ : un des messages forts de l'epoque, c'etait que Gnome serait fait en C : on prendrait un langage simple puissant et clair. Je ne compte plus le nombre de developpeurs qui m'ont dit qu'il participaient a Gnome parce que c'etait en C ("le C, c'est plus propre", "je comprends mieux ce que je fais", ...). Ceux-la sont particulierement mal a l'aise avec le soutien fort de MDI a Mono. Il est oblige pour ne pas s'aliener cette base importante de developpeurs de maintenir que Gnome ne sera jamais developpe en Mono mais plus ca va, moins c'est vrai. De fait, le gtk en C n'est pas en phase niveau facilite d'utilisation avec les langages et lib modernes (java, C#, Qt/C++, python, ...)
[epoque de la liberation d'openoffice] OpenOffice, c'est genial, en 3 mois, on aura des composants Gnome : il s'est mis a mal les developpeurs d'abiword et de Gnumeric a qui il avait dit que ces deux logiciels seraient la suite office de Gnome. Surtout, ce n'etait qu'un effet d'annonce puisque 3 ans plus tard, on a pas plus qu'un vernis Gnome sur OpenOffice.
[renoncement de KDE a Corba]: les mecs de KDE ont rien compris aux composants, vous verrez que Corba, c'est vraiment de la balle. Celui que je plains le plus aujourd'hui, c'est Mickael Meeks. Alors qu'il a bosse pendant 3 ans sur bonobo pour le rendre vaguement utilisable en C, on est en train de le faire lentement passer a la trappe parce que trop complique a utiliser et trop lourd. Gnome se retrouve donc a pousser discretement le nouveau DBUS qui ressemble beaucoup au DCOP de KDE. La aussi, probleme de discours marketing car il semble difficile de mettre bonobo a la poubelle apres l'avoir pousse aussi longtemp. Et ceux qui y croyaient a fond sont decus.
Et il y en a eu d'autres des derapages de MDI jetant la confusion sur la ligne directrice de Gnome. Pour formaliser le soutien de Sun, MDI a cree la Gnome Foundation mais la aussi, la base hackers qui n'aime pas les entreprises commerciales n'a pas forcement aime le principe de la Gnome Foundation comme le signale le post plus haut.
Le focus sur l'amelioration de l'ergonomie oblige a changer un certain nombre d'habitudes, ce qui n'a pas plus du tout a la fois dans le principe et dans la facon dont cela a ete fait a aliene une partie de la base des developpeurs qui aimaient mieux l'ancienne facon. Il faut voir que Gnome est parti d'un bureau de hacker, qui se distinguait de KDE (le bureau pour debutant qui ressemble a windows) par son cote hacker, pour changer de message et etre un bureau avec volonte de seduire les utilisateurs d'entreprise par sa simplicite.
L'accumulation de tout ca conduit a ce fork que j'interprete vraiment comme un "je veux retourner au temps de Gnome 1.0", c'est a dire "je veux retourner aux messages du temps de Gnome 1.0": un bureau de hacker, en C, simple a comprendre (fichiers de conf en texte, un seul composant html, ...)
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 6.
Oui. Je pense que c'est le probleme no 1.
> Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire.
Non. Les quelques constructeurs hyper motives qui veulent sortir des drivers pour Linux y arrivent tant bien que mal apres beaucoup d'efforts.
Imagine une boite qui fait un peripherique a la con. 95% de son marche est sous windows, 5% sous Linux (je suis tres optimiste, normalement, c'est 99.99999% ). Elle passe 2 ans a developper son driver avec son equipe de 2 personnes et il marche sous tous les windows. Elle est contente.
Mainenant, cette boite n'a aucun a priori sur Linux. Elle se dit que ca pourrait etre sympa de recuperer les 5% restant. De toute facon, sa version windows ne lui coute en maintenance que quelques jours-hommes par an donc elle a un tout petit peu de temps libre.
Voila qu'elle decouvre que si elle veut faire des drivers pour Linux, il faut qu'elle les fasse pour une version de Linux donnee. Ensuite, il faut qq'un qui suive en permanence l'evolution du kernel pour garantir que le driver n'est pas pete a chaque seconde qui passe. Sa maintenance va se chiffrer en mois-hommes parce que tout Linus a decide que l'api utilisee par le driver etait de toute facon pourrie et obsolete et va donc re-ecrire un truc completement incompable.
On imagine que la boite suit cette premiere transition. Apres, bien que le truc ait ete re-ecrit, il y encore des modifs a apporter a l'API du machin qui sont faites tranquillement, sans communiquer plus que un message sur la lkml, et qui petent le driver de nouveau.
Pour resumer, en terme de cout, un driver sous Linux, c'est quelque mois-hommes par an alors que le marche lui-meme est beaucoup plus faible que sous windows.
Le choix est vite fait pour n'importe quelle entreprise, il n'y aura pas de driver pour Linux. Mais ca Linus s'en fout apparemment.
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 1.
> pas dans le code du driver des hacks qui créeront des
> incompatibilitées avec des versions futures à cause de changement
> internes au noyau
Oui, mais dans ce cas, tu peux faire un report de bug clair incriminant le driver. Maintenant, la situation, ce sera "ca marche pas" sans que tu saches si un truc subtil a change dans le noyau, dans le driver, si le driver est code comme un pied ou si tu as un probleme sur ta machine.
Personellement, je considere ce modele de developpement comme une regression. Certe Linus aura moins de difficulte. Par contre, ca va etre la merde pour tout le monde en dehors de ceux qui suivent la lkml.
Les noyaux vont etre beaucoup moins testes par les utilisateurs puisqu'une mise a jour deviendra une operation tres dangereuse si on n'est pas sur de maitriser.
De tres gros projets arrivent tres bien a gerer l'evolution d'une base de code stable avec une evolution rapide (Mozilla, KDE, Gnome, Qt, Gtk) tout en conservant la compabilite binaire. Je ne vois pas pourquoi le noyau n'y arriverait pas. En fait, si , je vois tres bien. C'est parce que ca ne plait pas a Linus. C'est pas assez fun, c'est bien plus fun de tout peter a tout moment parce que ca nous plait que de conserver des API mouvante parce que soi-disant, ca va ameliorer la qualite des drivers.
Plus ca va, plus Linus fout la merde dans Linux. Mais c'est son bebe, on n'a rien a dire.
La phase "mais non, c'est pas dur de recompiler son noyau" ne pourra plus etre valable du tout.
Ca m'enerve vraiment. Quand je vois tous les efforts deployes par Trolltech, KDE ou Gnome pour qu'une mise a jour incompatible des lib se passe le plus tranquillement possible du monde, j'admire. Ils ne font ca que tous les 2 a 4 ans, ils preparent de bibliotheques de compabilite, ils preparent les developpeurs pendant plusieurs mois en faisant des snapshots, ils communiques, ils reflechissent longtemp a l'avance a ce qu'ils vont changer.
Linus, lui s'en bat tout simplement les couilles et je trouve ca dommage. Il a toujours eu cette attitude mais la ca devient vraiment genant. Le 2.6 ne pourra plus etre considere comme un noyau de reference.
[^] # Re: Oui mais..
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouvelle forme d'arnaque : l'usurpation d'identité de site web via XUL. Évalué à 10.
Le probleme souleve est au coeur du fonctionnement de XUL. A premiere vue, le spoofer fait exactement ce pour quoi XUL a ete prevu. Donc la facon la plus simple de remedier au probleme, c'est de supprimer l'execution XUL. Ah ouai, mais ca risque de serieuseement diminuer les possiblites du browser.
Bref, avant de predire, j'attends de vois ce que va proposer la communaute mozilla.
[^] # Re: apt
Posté par Philippe F (site web personnel) . En réponse au sondage Je réinstalle Linux sur mon ordinateur. Évalué à 2.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
De fait, il y a des gens plus interessants et plus senses dans Gnome qui font heureusement avancer les choses de facon intelligente.
Cela dit, gtk#, je pense que c'est un bon concept. N'import quel langage objet me parait preferable a du C pour coder une appli graphique.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Non, j'avoue avoir beaucoup de mal a te suivre dans tes raisonnements. Si plutot que de faire du delire, tu t'exprimais en phrases claires argumentees en parlant de faits reels ou au moins en proposant des explications qui se tiennent logiquement et socialement, ca serait plus facile de discuter avec toi.
> > C'est juste que dire que Ximian est completement independant de
> > Gnome et vice versa, ce n'est pas tout a fait vrai.
>
> Et tu veux en venir où ?
Je veux en venir au fait que quand tu dis que MDI est completement independant de Gnome, ce n'est pas vrai. MDI a encore via Ximian et via d'autre manieres une certaine influence sur le projet Gnome, bien qu'il n'en soit plus le leader ni meme un contributeur.
Et le fait que MDI bosse sur Mono encourage la communaute Gnome a reflechir autour de Mono. Ce n'est pas negatif mais c'est indeniable.
Et pour revenir a mon argumentation originelle (car perso, je tiens ma ligne de raisonnement), les differentes declarations de MDI ont enerve ou decu au cours du temps un certains nombre de membres de la communaute Gnome (car tout le monde dans Gnome ne voue pas une admiration sans borne a MDI et ses methodes). La direction actuelle de Gnome a largement ete insuflee par MDI et elle est differente de ce dont il faisait la promotion au moment de Gnome 1.0 et meme avant.
Donc il y a un certain nombre de mecontents chez Gnome qui se retrouveront probablement dans ce fork. Non, a peu d'exceptions pres, ils n'iront pas vers KDE car ils aiment bien le framework Gnome et ce qu'ils en ont fait. En revanche, ils ne sont pas necessairement en accord avec la direction pro-entreprise, pro-simplification qui (mais je me repete) etait loin de faire partie de Gnome dans sa version initiale. A l'epoque, c'etait meme Gnome le bureau de hacker hyper configurable et KDE le bureau pour les neuneu venant du monde windows.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Pour les seconds, Gnome a choisi de cacher pour pas que les premiers tombent dessus. KDE a fait le choix de les considerer comme des utilisateurs legitimes et de leur donner aussi une belle interface graphique.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
> C'est claire.
Ca ce n'est pas vrai. Il n'a pas ecrit de code pour Gnome mais il contribue au projet autrement. Il pousse le desktop dans les entreprises, il developpe evolution pour que Gnome puisse etre accepte en entreprise.
Il continue aussi a avoir son role de visionnaire. Quand il voit une bonne techno et qu'il pond un article en disant a quelle point elle est interessante, tous les hackers de Gnome regardent ce qu'il dit. Et ca n'a rien de negatif. MDI est un hacker de Gnome respecte pour sa contribution par les autres hackers de Gnome, donc quand il dit qqch, les autres l'ecoute.
Bref, nier qu'il y a encore des liens entre MDI et Gnome me parait un peu extreme comme attitude. Cependant, c'est sur qu'il n'est pas a la direction de Gnome et qu'il repete toutes les jours que Gnome ne sera pas developpe en mono. A ton avis, pourquoi il a besoin de le repeter autant ? Serait-ce parce que en raison de son role historique dans Gnome, des gens s'imaginent le contraire ?
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
- fond d'écran
- économiseur d'écran
Comme tu peux faire ces deux choses sans passer par le centre de controle, l'ergonomie de celui-ci est un tout petit peu moins importante.
Perso, dans le centre de controle KDE, comme il est complique, j'utilise tout le temps la fonction recherche. Je trouve tout ce que je veux du premier coup.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
Ce que te dis le monsieur, c'est que pendant quelques temps, la page de download officielle de Gnome etait chez Ximian. Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien), justement pour montrer que Gnome est bien independant dans la mesure du possible de Ximian et eviter les polemiques "Ximian controle gnome etc"
Exhiber la page de download actuelle et sortir ton delire sur Redhat ne change rien au fait que ce dont on parle est arrive.
Pour eviter toute surinterpretation, ce n'est pas mal que Ximian aie des liens forts avec Gnome. Ils contribuent avec evolution et les developpeurs de Ximian sont de tres gros contributeurs de Gnome et sont tres respectes.
C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
[^] # Re: C'estle genre de brevets qui peut faire avancer les choses
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft et Apple poursuivis pour violation de brevet. Évalué à 3.
Exemple auquel j'ai ete confronte : transposition dans le monde de le carte a puce d'une technique logicielle a la con utilise couramment dans les appli non embarquee.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
Et non, ce ne sont pas eux les responsables. Au contraire, ils ont fait un travail formidable dont l'ampleur est probablement mal appreciee.
Les responsables, ce sont qui ont affirme haut et fort que Corba etait parfaitement adapte comme modele de composant pour un desktop et ont continue sur ce choix technique. Ils ont fait fi de l'experience de KDE qui a renonce a CORBA a bout de deux ans de galere et ecrit un remplacant en moins d'un mois.
Corba est une tres bonne techno, mais c'est trop lourd par rapport aux besoins d'une techno de composant desktop. Donc il y a eu un travail enorme qui a ete fait pour rendre CORBA accessible relativement simplement en C. Du coup les developpeurs sont tellement pris dans Corba que documenter l'interface bonobo relativement triviale, ca leur parait superflu (ce dernier point est ma petite interpretation).
A cote, KDE est parti d'une techno existante et l'a a peine modifie pour en faire une techno de communication qui convenait parfaitement.
Et ce choix technique de CORBA, MDI en est en partie responsable. Comme il est responsable de pas mal d'autres choses chez Gnome, en bien comme en mal.
[^] # Re: ho sigh, windows...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 4.
Non, je ne vois pas ca comme une insulte mais ca m'agace profondement oui.
> que le but des développeurs de KDE, c'est de faire une interface de qualité qui ne soit pas déroutante pour les utilisateurs qui viennent de Windows
C'est la qu'il y a un probleme. Le but de KDE est de faire une interface conviviale pour tous les utilisateurs. Cela inclut les utilisateurs de windows, de MacOS, de Gnome, de Mozilla, ...
Quand les devs font des choix d'ergonomie, ils essayent de prendre tous ces parametres en compte, en soupoudrant ca de bon sens et de connaissances en ergonomie.
C'est pour ca que je trouve ca tres reducteur de dire qu'on ne vise que les utilisateurs de Windows, et que ca ignore tout le travail de fond fait par certains developpeurs (Waldo Bastian, Aaron Seigo)
Par exemple le simple-clic par defaut (dont personellement j'ai horreur) a ete choisi en raison de l'influence plus faible sur la degradation physiologique de la main.
L'ordre des bouton, c'est pour moi un debat ininteressant au possible.
L'explorateur de fichier sous KDE, je le trouve trop complique personellement. Beaucoup trop de menus, mal organises. D'un autre cote, il a des bons cotes et il est defendu comme un bon outil.
Pour le centre de controle, c'est pas facile de l'ameliorer sans trop bousculer les habiltudes des utilisateurs, et gardant toutes les options mais en conservant l'ergonomie.
Pour ce qui est du menu K, je ne vois pas ce que tu veux dire. Je regarde des screenshots du menu Gnome et je vois pas en quoi il ne ressemblerait pas a celui de windows, ou en quoi celui de windows ressemblerait plus a celui de KDE (pour anecdote, sous windows, j'ai reorganise mon menu demarrer "a la KDE" ou "a la linux" avec des applis internet, systeme, graphique et multimedia)
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
> (mon dieu, on ne peut pas défendre Gnome sans insulter KDE pour toi ?)
Non, je me posais la question en toute sincerite. J'ai l'impression qu'on parle beaucoup de l'ergonomie de Gnome, de HIG mais qu'on n'en parle tres peu pour KDE. J'arrive pas a determiner si c'est parce que les gens n'utilisent pas KDE du tout, pensent que KDE s'en fout completement ou sont satisfaits de KDE et donc n'envisagent pas de discuter ce point. Ou bien il existe peut-etre encore une autre explicatoin que je n'entrevois pas.
En fait, en y reflechissant, je vois une explication: KDE a la meme ligne de conduite et le meme HIG depuis 5 ans. Cote Gnome, ca genere des remarques puisqu'il y a eu un changement de strategie, d'un cote avec le choix d'exclure des options de config, de l'autre avec la publication du premier HIG, et enfin avec l'introduction de gconf.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Beaucoup plus de plats oui, mais j'ai pas eu l'impression que gconf-editor soit detaille. Il y a des explications pour les options ? De la doc.
L'avantage au moins du control center, c'est que les options sont clairement documentees et organisees.
<< un menu par défaut soigneusement étudié. >>
Juste une question comme ca : vous pensez que le menu de KDE n'est pas soigneusement etudie ? Le choix des defauts fait l'enjeu d'autant de d'attention qu'il le fait sur Gnome. Meme si les choix finaux sont differents, ils sont reflechis et portent une justification.
[^] # Re: ho sigh, windows...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 4.
Sinon, il y a des etudes qui montrent aussi que les gens s'adaptent tres bien a KDE.
Moi ca m'agace un peu ce "KDE ressemble a windows, Gnome ressemble plus au mac."
Si tu prends une demi-heure, tu peux faire ressemble KDE bien plus a un mac que Gnome. Barre des menu en haut, look aqua, ...
En fait, c'est un probleme de referentiel. Je trouve pas que KDE ressemble a windows mais ce qui est sur, c'est que dans l'esprit et dans le choix de couleurs ou dans l'organisation, on va retrouver des choses qu'on trouve aussi chez windows.
C'est quoi pour vous le fait que KDE ressemble a windows ?
Apres un coup d'oeil a differents screenshots, j'ai trouve: c'est le style des icones et le style Qt qui font que KDE ressemble a windows. Gtk a des widgets qui n'ont pas la meme taille ni la meme organisation que Qt. KDE en a qui ressemblent plus a ceux de windows. Ca combine au look'n feel des icones, ca fait qu'on se sent ailleurs quand on est sous Gnome.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Le format une ligne = une option, c'est plus facile a analyser que des tags imbriques qui sont la caracteristique du XML.
[^] # Re: ho sigh, windows...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 3.
En fait, tu veux une appli Gnome sans Gnome. Le but d'un desktop tel que Gnome etant au depart de fournir un ensemble d'applicaitons coherentes et integrees, il n'y a pas de raisons de rendre ce genre de dependance soit optionelle. Cela dit, tu peux patcher.
Si tu retires les dependances a Gnome, ca ne sera plus Gnome-terminal mais tu auras une application prete pour etre integree dans XFCE....
Tes besoins et ta philosophie correspondent plus a XFCE qu'a Gnome.
Sinon, a titre de curiosite, c'est quoi la killer feature de Gnome terminal qui fait qu'il t'es si indispensable ? A chaque fois que j'ai essaye Gnome, c'est justement Gnome-terminal qui m'a fait le plus souffrir a cause de ses limitations par rapport a konsole (il s'agissait de Gnome 1.4) donc je suis plutot curieux.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 4.
Si tu lis le debut du site web du mec, il resume tout dans une seule phrase: Gnome commence a utiliser des technologies qui l'effraient. Avant, il controlait tout: le C, gtk, les fichiers de config editables a la main, ... Maintenant, il y a beaucoup d'autres technologies, de programmation, de composant, de stockage des donnees et il n'aime pas parce qu'il n'a plus le controle absolu.
Vu son projet, il ferait mieux de se tourner vers des bureaux alternatifs type XFCE qui restent a mon avis dans sa philosophiie, plutot que de forker Gnome qui est parti dans une autre direction.
[^] # Re: PORTNAWAK
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 2.
Donc un nom plus generique et plus correct a ete choisi.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 6.
> Le configuration est lu une fois au début et c'est tout.
Non. D'une part, le simple fait de lire la configuration peut-etre une operation complexe. Typiquement sous KDE, tu as un setting system dans $KDEDIR/config/myapp/myapp.rc que tu peux surcharger avec un setting utilisateur $HOME/.kde/config/myapp/myapp.rc
Tu peux rajouter d'autres repertoires contenant des settings (suffit de les rajouter a $KDEDIRS) pour surcharger les settings systemes avant d'arriver aux settings utilisateurs.
Pour une application donnee, il se peut aussi que les settings soient repartis dans plusieurs fichiers de config. C'est notamment le cas quand tu vas utiliser un composant kpart. Par exemple kontact (l'equivalent d'evolution) va lire des setting kontact, des settings kmail et va lire aussi ta liste de contacts et no de telephones qui se situera ailleurs.
La configuration est aussi susceptible d'etre relue. Typiquement, quand tu fais 'appliquer' sur un panneau de config, tous les applications utilisant ce jeu de parametres sont notifiees qu'il a evolue et qu'il faut donc le relire.
Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Je me souviens que pour KDE 2, Waldo Bastian avait fait une grosse passe la-dessus et avait trouve par exemple que il est plus rapide de lire un fichier texte tout d'un coup plutot que ligne par ligne, et que il ne faut faire la conversion unicode que si on a besoin d'une chaine traduite. Ce genre d'optimisation avait permis de gagner quelques dizaines de secondes par ci par la, et en tout, c'est plusieurs secondes d'economisees.
En terme de temps de demarrage, tout est a prendre parce que l'utilisateur appreciera beaucoup.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 4.
XML n'est pas la panacee. C'est tres adapte pour faire des representations de donnees complexe, mais un bon fichier texte comme on en utilise depuis les annees 70 garde encore beaucoup beaucoup d'avantages.
[^] # Re: Gnome Leger?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 10.
C'est pour ca que dans toute appli graphique et notamment dans KDE, il y a pleins de hacks pour fournir au plus vite un feedback visuel et retarder au maximum les operations qui prennent de temps, de facon a les faire en arriere plan, quand l'utilisateur voit deja qqch.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 10.
Le texte ressemble vraiment a du "on va faire Gnome comme KDE" et de ce point de vue la est assez marrant.
Je pense que le probleme de Gnome, c'est de ne pas avoir garde un message directeur et une vision d'ensemble coherente depuis ses debuts.
Si tu regardes KDE, ils sont encore exactement dans la lignee du post de Mathias Ettrich du 1998.
Au contraire, les leaders de Gnome, et notamment MDI ont fait passer plusieurs messages differents au cours des annees, avec une attitude assez demagogue. A chacun de ces messages differents, un groupe different s'est rattache a Gnome. Aujourd'hui, ces differents groupes sont decus parce que Gnome n'est pas ce qu'on leur avait promis a l'epoque d'ou cette accumulation de mauvaise humeur et cette envie de retourner au temps de Gnome 1.0
Pour expliciter un peu plus la partie messages directeurs de Gnome:
[fondation de Gnome] KDE ca pue, c'est fait avec Qt qui est pas libre : ca c'etait le message initial. On va faire un bureau vraiment libre, d'ou rapprochement avec la FSF.
Ceux-la (et RMS en fait partie) sont decu par les dernieres orientations de MDI vers Mono sous licence Mit et par l'orientation resolument tres commerciale de Ximian
[fondation de Gnome] Qt, ca pue c'est du C++ : un des messages forts de l'epoque, c'etait que Gnome serait fait en C : on prendrait un langage simple puissant et clair. Je ne compte plus le nombre de developpeurs qui m'ont dit qu'il participaient a Gnome parce que c'etait en C ("le C, c'est plus propre", "je comprends mieux ce que je fais", ...). Ceux-la sont particulierement mal a l'aise avec le soutien fort de MDI a Mono. Il est oblige pour ne pas s'aliener cette base importante de developpeurs de maintenir que Gnome ne sera jamais developpe en Mono mais plus ca va, moins c'est vrai. De fait, le gtk en C n'est pas en phase niveau facilite d'utilisation avec les langages et lib modernes (java, C#, Qt/C++, python, ...)
[epoque de la liberation d'openoffice] OpenOffice, c'est genial, en 3 mois, on aura des composants Gnome : il s'est mis a mal les developpeurs d'abiword et de Gnumeric a qui il avait dit que ces deux logiciels seraient la suite office de Gnome. Surtout, ce n'etait qu'un effet d'annonce puisque 3 ans plus tard, on a pas plus qu'un vernis Gnome sur OpenOffice.
[renoncement de KDE a Corba]: les mecs de KDE ont rien compris aux composants, vous verrez que Corba, c'est vraiment de la balle. Celui que je plains le plus aujourd'hui, c'est Mickael Meeks. Alors qu'il a bosse pendant 3 ans sur bonobo pour le rendre vaguement utilisable en C, on est en train de le faire lentement passer a la trappe parce que trop complique a utiliser et trop lourd. Gnome se retrouve donc a pousser discretement le nouveau DBUS qui ressemble beaucoup au DCOP de KDE. La aussi, probleme de discours marketing car il semble difficile de mettre bonobo a la poubelle apres l'avoir pousse aussi longtemp. Et ceux qui y croyaient a fond sont decus.
Et il y en a eu d'autres des derapages de MDI jetant la confusion sur la ligne directrice de Gnome. Pour formaliser le soutien de Sun, MDI a cree la Gnome Foundation mais la aussi, la base hackers qui n'aime pas les entreprises commerciales n'a pas forcement aime le principe de la Gnome Foundation comme le signale le post plus haut.
Le focus sur l'amelioration de l'ergonomie oblige a changer un certain nombre d'habitudes, ce qui n'a pas plus du tout a la fois dans le principe et dans la facon dont cela a ete fait a aliene une partie de la base des developpeurs qui aimaient mieux l'ancienne facon. Il faut voir que Gnome est parti d'un bureau de hacker, qui se distinguait de KDE (le bureau pour debutant qui ressemble a windows) par son cote hacker, pour changer de message et etre un bureau avec volonte de seduire les utilisateurs d'entreprise par sa simplicite.
L'accumulation de tout ca conduit a ce fork que j'interprete vraiment comme un "je veux retourner au temps de Gnome 1.0", c'est a dire "je veux retourner aux messages du temps de Gnome 1.0": un bureau de hacker, en C, simple a comprendre (fichiers de conf en texte, un seul composant html, ...)