C'est en effet l'argument qui a recu le plus de publicité et c'était le problème le plus visible. C'est ce qui a permis au camp Gnome de garder la tête haute en disant que comme orbit serait meilleur, il n'y auraient pas les problèmes de KDE. Ils auraient dû y regarder d'un peu plus pres :
On voit bien que Corba ne répondait pas à la problèmatique pour laquelle on voulait l'utiliser. Un des premiers paragraphes du tutorial de bonobo contient une phrase du type << bonobo peut via corba afficher dans une application un composant graphique executé sur une autre machine et ecrit dans un autre lanage. Il doit y avoir quelqu'un sur terre qui a besoin de cette fonctionnalité >>
Pour moi, ca souligne que l'interet principal de Corba (la distribution de composants sur plusieurs machines) ne trouve pas d'utilité ni dans Gnome, ni dans KDE. Donc pourquoi s'embarasser de Corba ?
J'ai pas dit que c'était nouveau, j'ai dit que c'etait là.
> C'est révolutionnaire
Je ne pense pas non.
> De plus le C ce n'est pas un language de merde
Non. Même, je vais te surprendre mais j'aime bien coder en C. Par contre, coder un Gtk n'a pour moi rien à voir avec du C. Quand je fais des classes, de l'héritage et que je manipule le concept de surcharge de méthode, je préfère utiliser un langage objet où ces paradigmes font partie du langage et ne sont pas rajoutés à coup de bricolage macroesque incertain.
Pour ce qui est de la programmation d'interface graphique, je pense que le C est << un langage de merde >> pour reprendre tes mots. Et ce pour les raisons que je viens d'évoquer.
L'idée de mon post était de rappeler qu'en terme de facilitation de développement d'applications graphiques, KDE a pas mal de mécanismes, la plupart basés sur XML, qui permettent de faire beaucoup de choses de façon automatisée (génération automatique de stub pour dcop) et que au lieu de lorgner en permanence du côté de Microsoft pour de l'innovation, la ximian team ferait bien de regarder de plus pres ce qu'il y a dans KDE et dans les autres projets comme GnuStep.
> Et il a raison sur la proposition d'avoir un language de script central
Malheureusement, ca ne sera pas possible dans la communauté du libre car chacun a son langage de script favori et aucun ne peut vraiment l'emporter. Pour les emacsien, c'est le lisp, RMS recommande le scheme, certains penchent pour python, d'autre ruby, d'autres perl, d'autre Javascript, d'autre C#, lua, Objective Caml, ...
C'est plus facile coté microsoft puisque tout le monde boit ce que dit Bill Gates. A noter quand meme que pendant longtemps, le basic VB etait incompatible avec le basic Access, lui-même incompatible avec sa version précedente, et que tout ca est incompatible avec le basic VB.NET . Bref, faut pas croire que tout est aussi rose que le marketing veut bien le dire. Je me demand même si on n'a pas la vie plus simple, parce qu'au moins, on sait à l'avance que python ne veut pas dire perl.
Ce qui est important, c'est en terme de diversité de langage, c'est que chacun aie accès de la même façon au coeur Gnome ou KDE. La seule facon de garantir cela, c'est de générer automatiquement les bindings comme le font aujourd'hui KDE et Gnome.
> Gnome est toujours là et en pleine forme.
Il est toujours là mais pour moi, il n'est pas en pleine forme. Il a coûté beaucoup plus cher que KDE et terme de mois-hommes. Et quand on regarde les rouages, KDE est beaucoup plus avancé. En trois lignes de bash, je peux m'amuser à faire un fond d'écran dynamique avec mes photos de vacances, sans aucune connaissance précise sur KDE en dehors du fait de taper kdcop.
Un copain qui a fait du Next m'a dit en effet en voyant Qt 1 qu'ils n'avaient fait que reprendre des conccepts déjà présents dans Next. Normal que GnuStep en hérite.
Redhat a un très mauvais historique avec KDE et Qt. On se demande depuis longtemp si ils ne font pas exprès de rendre KDE à moitié inutilisable sur Redhat. C'est triste car une très grosse part d'utilisateurs de KDE est américaine et utilise de fait Redhat.
La situation devrait s'améliorer avec Fedora qui a l'air beaucoup moins fermée que ne l'était Redhat.
> Compare avec la doc, il en manque plein.
Je sais pas si ils y sont tous, j'ai juste dit que aucun ne m'avait manqué. J'ai réussi à faire exactement ce que je voulais sans ressentir de limitation. Lequels t'ont manqué ?
Une différence notable entre Trolltech, Mozilla et Microsoft, c'est que les deux premiers ont un très bon historique dans la communauté du libre.
Tu as l'air de t'offusquer qu'on puisse ne pas faire confiance à Microsoft ! Ca me parait pourtant une attitude naturelle compte tenu de leur historique
> KDE a aussi fait quelques erreurs [...] mais et une bonne solution a été trouvée à chaque fois
Exception : arts. Je ne sais pas pourquoi KDE traine encore ce truc mais ce n'est pas du tout dans la ligne du reste de KDE. J'espere qu'ils s'en débarasseront un jour et qu'ils passeront a gstreamer.
> Corba et bonobo sont toujours là et il n'y a rien qui indique que ça va être viré.
De fait. Je pense que ca continue à freiner le développement de Gnome mais je n'ai pas dit que ça allait être viré. Pendant que Michael Meeks codait bonono pendant ses un à deux ans (parce que c'est une grosse bete), les hackers KDE faisaient avancer KDE.
> Il n'y a pas un début d'embryon de discussion pour changer de language pour les librairies.
Je n'ai rien dit de tel non plus. Gnome va rester en C et là aussi, je pense que ca ne contribue pas à accelérer son développement. Pendant que Owen (c'est bien lui) codait GObject pendant 6 mois, les hackers KDE faisaient avancer KDE.
> C# est comme python, C++, perl, ada, ... pour Gnome. C'est un binding et c'est tout.
Oui. Ai-je dit le contraire ? J'ai l'impression que tu te trompes de Troll. Ici, c'est pas << Gnome va être ré-écrit en C# >>, c'est << MDI change d'avis tous les deux ans et fout les projets auquels il participe dans la merde avant de se barrer >>
> gtk# c'est pas la réécriture de gtk en C# par exemple ! C'est un binding comme un autre.
Yeps. Comme Qt#. Mais je vois pas le lien avec la discussion que j'ai eu plus haut.
> C'est vrai que tous les développeurs Gnome sont des cons et suive le gourou MDI sans réfléchir.
En tout cas, ils ont tous mordu à l'hameçon Corba alors que c'était une grosse connerie et qu'ils en avait la preuve juste sous les yeux. Et oui, MDI a du charisme et a entrainé beaucoup de gens avec lui, notamment dans Gnome, avant de les laisser dans la merde et de commencer un autre projet.
Même RMS y a cru. Lors de l'interview que KDE France a fait de lui à la linux expo 2003, il a dit qu'il regrettait d'avoir autant suivi Miguel et qu'il voulait maintenant se rapprocher plus de KDE.
> D-BUS est plus simple et n'a pas les objectifs de Corba et ne remplacera pas Bonobo.
Heureusement qu'il n'a pas les objectifs de Corba parce Corba est compètement indadapté aux besoins d'un protocole de communication inter-application de bureau. D-BUS a les objectifs de servir de protocole de comme entre les applis de bureau et le matériel. En ce sens, il va un poil plus loin que DCOP mais à l'époque ou DCOP a été concu, l'USB et le hotplug était de la science fiction donc on peut comprendre qu'ils n'ont pas abordé cette problèmatique de front.
D-BUS ne remplacera pas Bonobo en effet. Pour remplacer bonobo, il faut DCOP + KPart, c'est à dire un protocole de communication + une système de composant. Tout est déjà présent dans Gtk et dans Gnome pour faire un équivalent de KPart bcp plus léger que bonobo. En fait, en tant que simple programmeur KDE, j'ai réussi à faire un composant pour une application Gtk (gvim) en passant par des GtkSocketPlug. Donc un hacker Gnome, si il lui en prenait l'envie, serait probablement capable de cracher un système de composant léger en moins d'une semaine, le temps qu'il a fallu pour faire kpart. On attendra encore un ou deux ans pour que ça arrive, le temps qu'ils se désintoxiquent compètement de Corba et qu'ils oublient que KDE a déjà la solution.
> Premièrement ton truc au-dessus est bourré de connerie.
Pour l'instant, on peut pas dire que tu as avancé un seul argument qui tienne la route pour me donner tort, au contraire.
> Deuxièmement MDI ne s'occupe plus de Gnome depuis la version 2.0.
De fait. C'est ce que je soulignais en disant que MDI change d'avis tous les deux ans et laisse les projets en plan.
MDI a ça pour lui que quand un projet commence à être dans la merde, il se barre en douce. Ca m'étonne pas qu'il soit plus dans Gnome. Il faudra plusieurs années à Gnome pour se remettre de sa présence mais le projet redécollera peut-être.
> 2) Le choix du C c'est pas pour faire warlordz, c'est parce qu'on peut plus facilement faire des bindings faire d'autres langages.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.
Je ne lui reproche pas d'évoluer et de changer d'avis. C'est une qualité d'être capable de revenir sur ses actes et de reconnaitre ses erreurs. Par contre, quand on entraine avec soi tout un projet de la taille de Gnome, on est prié de reflechir bien au futur et à toutes les solutions existantes. Ce qu'il n'a pas fait.
Je lui reproche de prendre en moyenne 2 ans pour s'apercevoir qu'il s'était complètement planté alors que la solution était la sous ses yeux et qu'il a refusé de l'utiliser. L'exemple de corba est tres parlant et ce n'est pas le seul. KDE a été hué et critiqué énormement pour leur absence de reflexion quand ils ont laché corba. Pourtant, n'importe qui prenant la peine d'analyser les raisons qui les ont pousser à rejeter Corba et à choisir une solution DCOP + KPart aurait vu que leurs raisons étaient tout à fait valides et que Gnome allait rencontrer les mêmes problèmes. Mais visiblement, _personne_ chez Gnome n'a pris la peine de faire ces démarches et bonobo reste une usine à gaz.
Pour ce qui est de la communication entre applications, Gnome reste très pauvre alors qu'on peut scripter n'importe quelle application KDE avec DCOP. D-BUS semble apporter une solution un peu plus riche et ô surprise, c'est un DCOP sans la dépendance X. Là encore, on frise les 4 ans pour s'apercevoir de l'interêt d'une technologie pourtant déjà mature dans un projet qu'ils ont sous les yeux. Si tu regardes les arguments qui sont utilisés pour D-BUS, ce sont les mêmes qui ont été avancé à l'époque où KDE 2 n'était même pas encore sorti.
Donc faire des erreurs, je veux bien. Mais être aussi aveugle, je pense qu'il faut vraiment y mettre de la mauvaise volonté. Apparemment, toute la clique Ximian lorgne maintenant beaucoup plus du côté de Microsoft que du côté de KDE.
KDE a aussi fait quelques erreurs mais la très grosse différence, c'est que des personnes qui réflechissaient objectivement (et pas en terme hype ou en lisant les press release de Microsoft) à tous les problèmes et les avantages d'une solution ont participé à la reflexion et qu'une bonne solution a été trouvée à chaque fois. La meilleure preuve, c'est qu'ils n'ont rien changé depuis 4 ans à dcop et kpart.
KDE a aussi choisi Corba mais s'est rendu compte de son erreur en moins d'un an. De plus, le projet a gardé la même ligne de conduite depuis sa création alors que Miguel n'a cessé de changer d'avis tous les deux ans comme je le soulignais là-haut. L'avantage, c'est que le projet a pu avancer de façon cohérente, alors que Gnome se disperse beaucoup et que beaucoup d'appli soi-disant Gnome sont en fait soit des applis Gtk, soit des applis Gnome 1, soit (pire) des applis Gtk 1. Bref, ca contraste beaucoup avec KDE et sa ligne de conduite claire.
Je suis surpris par ce que tu dis parce que j'utilises Qt Designer regulieremeent et il ne m'a jamais fait planter une appli et je n'ai pas trouve de widget manquant par rapport a mes besoins.
J'ai juste trouve deux trucs lourds, c'est de devoir casser des layout pour pouvoir ajouter un objet et le fait qu'on puisse pas creer des widgets customs heritant d'un widget connu.
Oui, c'est vrai. Il analyse bien les problemes. En revanche, il a le chic pour proposer la mauvaise solution.
Par exemple, si tu lis un des papier fondateurs de Gnome sur la critique des programmes unix et la complexite de faire travailler ensemble des outils graphiques, il a 100% raison.
Sa solution en revanche est toute pourrie: corba. On ne connais pas plus lourd, et les developpeurs sont encore en train de se battre avec la gestion de la destruction des resource partagees entre plusieurs processus.
A cote de ca, KDE a trouve la solution simple et efficace depuis 4 ans (KDE 2 est sorti en 2000) avec dcop et kpart. Mais MDI prefere croire que bonobo est la bonne approche et faire depenser un temps fou a ses developpeurs. Regardez la gueule du code pour gerer des objets corba, des exceptions et un IDL en C pour vous marrer un jour.
> On est nombreux à utiliser Gnome et evolution et à dire que mono nous permet enfin d'avoir un équivalent à C# et à ne pas passer pour des ploucs face à MS.
Desole, je ne fais pas partie des nombreux et je pense au contraire qu'avaler la couloeuvre mono toute crue vous fait passer pour des ploucs de chez Ms.
> Bref, il fait avancer les choses et concrètement.
Ah ouai ? Regardons un peu l'historique de MDI:
<<
- tiens, KDE c'est pas mal mais c'est du C++, c'est chiant les objets et tout ca et en plus Qt c'est QPL, c'est pas assez libre. Faisons Gnome en pur C et LGPL, ca pourra etre que mieux.
[ 2 ans plus tard ]
- putain, ce qu'il faudrait, c'est pouvoir echanger facilement des composants graphiques. On va utiliser Corba, ca a l'air hype. On va pas regarder tous les problemes qu'ont les developpeurs de KDE avec corba, c'est des mauvais, ils savent pas coder. Et puis de toute facon, Qt, c'est GPL, c'est trop libre. [1]
[2 ans plus tard]
- putain, corba et bonobo, c'est le bordel. C'est dingue ce que ca peut etre complique de gerer des resources entre plusieurs processus a temps de vie variable de facon asynchrone. [2] Et puis on passe quand meme vachement de temps a utiliser Corba. Il faut lire seulement un bouquin de 1000 pages pour ecrire un composant graphique en corba, j'ai peur qu'on soit a cote de notre objectif du partage facile de composant graphique entre application. En fait, il va nous falloir vachement de temps pour rendre tout ca simple et accessible en C.
[2 ans plus tard]
- putain, le C, c'est pas top. En fait, pour faire des classes et des objets avec de l'heritage, des methodes virtuels et du typage fort, le C est pas adapte. Je sais pas pourquoi on y a pas pense plus tot mais il nous faudrait un langage oriente objet. Un truc genre C++ mais on aurait l'air con si on recommendait C++ apres avoir attire les developpeurs sur Gnome en leur diisant qu'ils feraient du C pur. Donc faudrait autre chose. On pourrait prendre le truc de Microsoft, C#. C'est hyper hype, ca sera bon pour nous.
[2 ans plus tard]
- putain, c'est dingue ce qu'on est efficace avec un langage objet. Vraiment, vous etes des loser en C, venez faire du C# avec Mono et Microsoft, c'est bien plus cool. Pour Gnome qui est ecrit en C, ben demerdez-vous, moi maintenant, je fais du C#.
[Dans 2 ans]
- putain, c'est dingue, Microsoft nous empeche de continuer Mono a cause de ses brevets, ses droits d'auteurs, le DMCA, ses copyrights sur les API et la pression sur les clients qui voudraient l'utiliser. Je sais pas comment on a fait pour ne pas le voir venir. Mais bon, j'ai la solution, on va lancer un nouveau projet qui n'aura rien a voir avec Mono et Gnome mais qui resoudra tous les problemes. Ah, pour les gens qui ont cru en moi et on fait du Gnome en C#, demerdez-vous. Moi, je suis sur mon nouveau projet.
>>
> Le logiciel libre, c'est la compétition. Les nazes sont rapidement repérés et virés.
Apparemment, les nazes ne sont pas si vites reperes puisque certains croient encore que MDI peut avoir des bonnes idees.
> MDI est toujours la
Dans Gnome ? Ah, non, il est plus dans Gnome. Mais oui, il est toujours vivant et il raconte toujours son lot de connerie, et tout le monde le croit encore.
[1]: De fait, apres le nombreux problemes lie a la complexite de Corba, l'equipe KDE a cree DCOP et KPart, qui rendent les services initialement prevu, mais sont beaucopu plus stables, tiennent chacun dans moins de 1000 lignes de code, ont ete ecrits en deux jours, sont rapides a charger et facile a controller. By by corba.
[2]: tire d'un Gnome Fondation summary. Dommage, j'ai perdu la reference mais qu'est ce que je me suis marre a le lisant. On aurait dit un mail de la liste de dev de KDE 4 ans plus tot. C'est des rapides chez Gnome pour comprendre les problemes.
Y en a qui devraient lire le "Fire and Move" de Joel On Software (http://www.joelonsoftware.com(...) ). En gros, le principe de Microsoft, c'est de sortir des nouvelles technos relativement rapidement et d'avancer ensuite tres rapidement vers la techno suivante. Quand une techno sort, Microsoft est au top avec et tous ses concurrents doivent depenser 2 a 3 ans d'energie pour l'integrer dans leurs produits/outils/langage marketing, ... Pendant ce temps la, Microsoft est deja sur la techno suivante. "Fire and Move".
MDI est bien parti pour etre le suiveur du siecle. Apres avoir lance Gnome pour suivre KDE, bonobo pour suivre Corba, Evolution pour suivre Outolook, mono pour suivre les pratiques de developpement moderne (vous savez, le truc ou pour ecrire un widget dans une appli, il n'y a pas besoin de 70 lignes de code C indigeste bourre de macro), on a maintenant droit a XAML. C'est pas Novell qui aurait du racheter Ximian, c'est Microsoft. Il se seraient sentis chez eux.
Bravo, vive l'innovation.
Comme par hasard, les deux gus se gardent bien d'aller regarder ce qui se fait du cote de KDE (des fois qu'il y aurait deja la solution) et preferent lorgner chez Microsoft. Bel esprit logiciel libre. On peut dire que la rivalite KDE / Gnome est loin d'etre inexistante chez certains. Vraiment, quand je vois qu'on peut preferer des solutions microsoft comme Mono avec tout le bagage de risque que ca comporte, alors qu'il y a des solutions eprouvees pour faire la meme chose du cote de KDE, ca me debecte.
Citons chez KDE:
- Qt Designer: 10 fois plus utilisable que Glade, permet de cracher une interface graphique en XML en 10 minutes. D'ailleurs, il relit les fichiers Glade. Bien que peu utilise, il y a la possibilite de livrer un fichier descriptif xml avec une application pour que le fichier soit charge dynamiquement et que l'apparence de l'application soit modifiable dynamiquement.
- Kommander: on genere une interface en s'appuyant sur Qt Designer et on fabrique un front-end en 10 minutes.
- XML Action: depuis KDE 2, l'organisation des menu et barres d'outils se fait via un fichier XML qu'on peut modifire dynamiquement
De ce que j'ai lu sur XAML, ca ressemble a ce qu'on peut faire en Visual Basic (associer un evenement sur un controle a une fonction executee) mais en XML. Ca ne resoud pas deux problemes fondamentaux:
- la programmation par evenement devient vite tres lourde. L'approche Gtk/Qt avec des signaux et des slots est beaucoup plus puissante
- une bonne interface graphique ne peut pas etre generee automatiqueement. Une bonne interface graphique, ca se travaille et ca prend du temps. Donc XAML ne pourra etre utilise que pour des interfaces graphiques de qualite moyenne. Pour arriver a un truc bien, il faudra passer autant de temps que avec Qt Designer.
Donc moi, je n'y vois qu'un n-ieme campagne de Microsoft reprenant des idees presentent ailleurs depuis des milliers d'annees et faisant croire que c'est un concept revolutionnaire.
Il y a un pinceau dans le styliste qui te permet d'appliquer un style donne a un mot, paragraphe, ... J'ai l'impression que tu parles de la meme fonctionnlaite
Beaucoup de journaux, techniques ou pas, acceptent des articles ecrits en francais correct, presentant clairement un enjeu ou une technologie. J'avais contacte des journaux un peu technique a l'epoque ou je voulais ecrire des articles sur Qt et j'avais eu une reponse favorable.
Tout a fait. Il y avait une tres bonne analyse de Linus je ne sais plus ou sur le sujet.
La force du logiciel libre, c'est la diversite de l'ecosysteme. Je fais partie de ceux qui pestent a cause de la separation des efforts, mais c'est ca aussi qui permet d'essayer des idees differentes et de proposer des solutions innovantes.
Il y a toujours deux approches possibles: la cathedrale ou tu fais tes plans et avec ton equipe, tu construis ton bazar. Tu sais ou tu vas et si tu t'es pas goure dans tes plans, ca marche. Sauf si t'avait pas vu au depart quelques subtilite qu'on ne rencontre qu'un milieu de projet.
Le bazar: tout le monde fait n'importe quoi et a la fin, ceux qui ont survecu et qui apportent qqch emergent. Ca prend plus de temps mais le resultat est plus robuste. Et surtout, il y a plusieurs voies qui sont envisagees.
Voire, quand tu discutes avec des dieux de X, ils te disent que la meilleure partie de X, c'est vraiment son protocole, qui a quand meme survecu 15 ans qui assure l'interoperabilite entre une vingtaine de serveurs X. Donc je doute que ce soit la partie a remplacer. C'est plutot en effet les aller-retours clients/serveurs et les operations synchrones qui posent des problemes.
En ce qui me concerne, je crois qu'aucun projet de serveur graphique ne pourra s'imposer sans une compabilite tres forte avec X au niveau de la base existante. Coup de bol, c'est prevu. M'enfin, je reste tres tres tres sceptique et je crois bcp plus a la re-ecriture de la xlib.
> - une lenteur certaine sous Linux et Windows (bien sûr pas sur les toutes dernières bêtes de course)
Ca, c'est vraiment un probleme. Sous windows, des que je fais tourner un firewall, un antivirus, oo avec plusieurs documents, firefox et thunderbird, ma machine commence tres tres nettement a manquer de RAM. C'est vrai, je n'ai "que" 256 Mo mais quand meme.
A cote, word ou excel ouvrent les documents tres tres rapidement, le lancement de IE est presque instantane.
> - certaines fonctionnalités sont loin d'être instinctives (essayez de mettre une page du milieu d'un rapport en paysage)
C'est bien explique et dans l'aide et dans les tutoriaux. Au contraire, une fois que tu as compris l'esprit, je trouve ca beaucoup plus instinctif et facile a utiliser.
> - l'aide est encore très limitée par rapport à celle d'Office
Moi je trouve au contraire qu'elle est beaucoup plus complete, beaucoup mieux redigee et beaucoup plus accessible. C'est grace a elle que je suis beaucoup plus productif sous OO que sous MsO.
> - il manque de nombreux modèles de documents (pour les présentations, les rapports...)
C'est relativement facile de se faire son modele donc ce ne me gene pas. La premiere fois, tu y passes une heure et apres c'est bon. De toute facon, un modele standard ne m'a jamais convenu et il a toujours fallu que je le modifie. La difference avec msO, c'est que sous OO, cette operation a ete extremement simple.
> - il n'y à pas de correcteur d'orthographe / grammaire du niveau de celui de Office (on en ai assez loin)
Le correcteur orthographique qu'on peut recuperer sur le site me suffit.
Bref, en dehors des gros problemes de lenteur, moi je trouve vraiment la suite excellente. Et avec la generation du pdf, il y a pas photo. Surtout quand on pense aux recents problemes des documents words...
Et tu crois dans Gnome ou KDE, il n'y a pas de plate-forme de programmation ? C'est tout pareil. Tu as des services pour tout ce que peut vouloir faire une application. La seule difference qu'on pourrait noter pour KDE, c'est que le concepteur graphique d'application (Qt Designer) n'est pas developpe par KDE meme mais par Qt.
> BeOs est en fait un Linux avec un serveur graphique
donc c'est comme XFRee
> un gestionnaire de fenêtre
Comme kwin ou metacity ou les 50 autres
> un gestionnaire de bureau.
Comme KDE ou Gnome.
Sachant qu'en plus, certains projets se basent sur XFree, il ne reste plus grand chose d'original.
Ca rejoint mon post plus haut. Ce qui faisait la specificite de BeOs, c'est son coeur et mettre ce coeur sur du Linux, ca veut dire perdre les specificites de BeOs et le mettre au meme niveau que Window Maker ou KDE.
> Si le noyau linux convient pourquoi en utiliser un autre ?
Mais le noyau linux convient-il reellement ? Pour faire du bon multimedia, on doit s'approcher d'un noyau temps-reel qui doit fournir des garanties de delai pour toutes les applications video ou sonores. Or le noyau linux a un scheduler classique et si la pre-emption cote utilisateur permet de gagner un peu en performance, il ne me semble pas que ce soit un vrai noyau oriente multimedia. Bien sur, sur une bete de course, il repondra aussi aux contraintes du multimedia mais qu'en est-il des perfs d'une machine moyenne ?
Je ne connais pas grand chose a BeOs donc corrigez-moi si je dis une connerie mais ce que j'en avais compris, c'est que c'etait un OS avec quelques services innovants ou originaux presents dans l'OS : micro-noyau, oriente multi-media, systeme de fichier en base de donees, ...
En refaisant l'API BeOS avec du Linux + XFree, on refait certe le look BeOS mais on perd le "feel", ce qui faisait l'atout de cet OS. Bref, ca n'a pas plus d'interet que KDE ou Gnome.
Qq'un de plus verse sur le sujet pourrait-il confirmer ou infirmer ?
Moi aussi j'aime beaucoup ce texte et le ton de l'auteur. A mon avis, il a bien plus le potentiel de convertir des newbie a linux que le discours habituel du linuxien ("windows, c'est mal!" etc etc)
Il montre aussi le point de vue d'un type qui n'y connais rien au depart , qu'on a un peu tendance a oublier. La premiere fois que tu modifies ton lilo.conf a la main, ca fait flipper. Mais apres, c'est que du bonheur.
Je suis personellement tres decu par cet aspect de gentoo. Il faut voir que avec la GPL, le developpeur a tres peu de droits alors que l'utilisateur en a beaucoup. Le copyright fait partie des rares prerogatives qui reste a un developpeur developpant un soft sous GPL. Sous gentoo, meme ce droit n'existe plus.
Je trouve que cela a aussi un cote mauvais esprit pour gentoo. Genre on est une distribution communautaire ou tout le monde est le bienvenu mais pour participer vous devez nous abandonner votre travail.
Sans compter que niveau legal, gentoo est loin d'etre clair. Pourquoi c'est Gentoo Inc. (une societe commerciale) et pas une assoce a but non lucratif qui recupere les copyright ? La possibilite que gentoo recupere le travail de ses contributeurs pour en faire une version proprio et se faire du fric ne me parait pas negligeable. J'avais entendu Daniel Robbins discuter avec un developpeur au Fosdem 2003 et il disait qu'il contactait des boites de jeu voulant sortir des jeux sous linux pour les faire passer a gentoo.
Bref, je suis un utilisateur de gentoo relativement heureux sur le plan technique mais decu par ces aspects. Gentoo traine quelques casseroles pour l'instant et j'espere qu'il n'y a pas de cadavre au fond du jardin.
Moi je dis bravo parce que c'est vrai que c'est un besoin relativement courant.
Cela dit, un gros avantage de subversion, c'est sa simplicite. J'ai rien eu a apprendre pour passer de cvs a subversion et ca c'est appreciable. Mais j'aimerai bien pouvoir faire ce qui vient d'etre decrit.
Notamment, il y a le cas ou qq'un veut faire un fork d'un projet et ou il est quand meme interessant de recuperer tout l'arbre de version du premier projet.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Tu peux lire l'intro de DCOP pour retrouver un peu les problèmes :
http://developer.kde.org/documentation/library/kdeqt/dcop.html(...)
http://developer.kde.org/documentation/books/kde-2.0-development/ch(...)
On voit bien que Corba ne répondait pas à la problèmatique pour laquelle on voulait l'utiliser. Un des premiers paragraphes du tutorial de bonobo contient une phrase du type << bonobo peut via corba afficher dans une application un composant graphique executé sur une autre machine et ecrit dans un autre lanage. Il doit y avoir quelqu'un sur terre qui a besoin de cette fonctionnalité >>
Pour moi, ca souligne que l'interet principal de Corba (la distribution de composants sur plusieurs machines) ne trouve pas d'utilité ni dans Gnome, ni dans KDE. Donc pourquoi s'embarasser de Corba ?
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
J'ai pas dit que c'était nouveau, j'ai dit que c'etait là.
> C'est révolutionnaire
Je ne pense pas non.
> De plus le C ce n'est pas un language de merde
Non. Même, je vais te surprendre mais j'aime bien coder en C. Par contre, coder un Gtk n'a pour moi rien à voir avec du C. Quand je fais des classes, de l'héritage et que je manipule le concept de surcharge de méthode, je préfère utiliser un langage objet où ces paradigmes font partie du langage et ne sont pas rajoutés à coup de bricolage macroesque incertain.
Pour ce qui est de la programmation d'interface graphique, je pense que le C est << un langage de merde >> pour reprendre tes mots. Et ce pour les raisons que je viens d'évoquer.
L'idée de mon post était de rappeler qu'en terme de facilitation de développement d'applications graphiques, KDE a pas mal de mécanismes, la plupart basés sur XML, qui permettent de faire beaucoup de choses de façon automatisée (génération automatique de stub pour dcop) et que au lieu de lorgner en permanence du côté de Microsoft pour de l'innovation, la ximian team ferait bien de regarder de plus pres ce qu'il y a dans KDE et dans les autres projets comme GnuStep.
> Et il a raison sur la proposition d'avoir un language de script central
Malheureusement, ca ne sera pas possible dans la communauté du libre car chacun a son langage de script favori et aucun ne peut vraiment l'emporter. Pour les emacsien, c'est le lisp, RMS recommande le scheme, certains penchent pour python, d'autre ruby, d'autres perl, d'autre Javascript, d'autre C#, lua, Objective Caml, ...
C'est plus facile coté microsoft puisque tout le monde boit ce que dit Bill Gates. A noter quand meme que pendant longtemps, le basic VB etait incompatible avec le basic Access, lui-même incompatible avec sa version précedente, et que tout ca est incompatible avec le basic VB.NET . Bref, faut pas croire que tout est aussi rose que le marketing veut bien le dire. Je me demand même si on n'a pas la vie plus simple, parce qu'au moins, on sait à l'avance que python ne veut pas dire perl.
Ce qui est important, c'est en terme de diversité de langage, c'est que chacun aie accès de la même façon au coeur Gnome ou KDE. La seule facon de garantir cela, c'est de générer automatiquement les bindings comme le font aujourd'hui KDE et Gnome.
> Gnome est toujours là et en pleine forme.
Il est toujours là mais pour moi, il n'est pas en pleine forme. Il a coûté beaucoup plus cher que KDE et terme de mois-hommes. Et quand on regarde les rouages, KDE est beaucoup plus avancé. En trois lignes de bash, je peux m'amuser à faire un fond d'écran dynamique avec mes photos de vacances, sans aucune connaissance précise sur KDE en dehors du fait de taper kdcop.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
La situation devrait s'améliorer avec Fedora qui a l'air beaucoup moins fermée que ne l'était Redhat.
> Compare avec la doc, il en manque plein.
Je sais pas si ils y sont tous, j'ai juste dit que aucun ne m'avait manqué. J'ai réussi à faire exactement ce que je voulais sans ressentir de limitation. Lequels t'ont manqué ?
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 0.
Tu as l'air de t'offusquer qu'on puisse ne pas faire confiance à Microsoft ! Ca me parait pourtant une attitude naturelle compte tenu de leur historique
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
Exception : arts. Je ne sais pas pourquoi KDE traine encore ce truc mais ce n'est pas du tout dans la ligne du reste de KDE. J'espere qu'ils s'en débarasseront un jour et qu'ils passeront a gstreamer.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 4.
Lesquelles ?
> Corba et bonobo sont toujours là et il n'y a rien qui indique que ça va être viré.
De fait. Je pense que ca continue à freiner le développement de Gnome mais je n'ai pas dit que ça allait être viré. Pendant que Michael Meeks codait bonono pendant ses un à deux ans (parce que c'est une grosse bete), les hackers KDE faisaient avancer KDE.
> Il n'y a pas un début d'embryon de discussion pour changer de language pour les librairies.
Je n'ai rien dit de tel non plus. Gnome va rester en C et là aussi, je pense que ca ne contribue pas à accelérer son développement. Pendant que Owen (c'est bien lui) codait GObject pendant 6 mois, les hackers KDE faisaient avancer KDE.
> C# est comme python, C++, perl, ada, ... pour Gnome. C'est un binding et c'est tout.
Oui. Ai-je dit le contraire ? J'ai l'impression que tu te trompes de Troll. Ici, c'est pas << Gnome va être ré-écrit en C# >>, c'est << MDI change d'avis tous les deux ans et fout les projets auquels il participe dans la merde avant de se barrer >>
> gtk# c'est pas la réécriture de gtk en C# par exemple ! C'est un binding comme un autre.
Yeps. Comme Qt#. Mais je vois pas le lien avec la discussion que j'ai eu plus haut.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
En tout cas, ils ont tous mordu à l'hameçon Corba alors que c'était une grosse connerie et qu'ils en avait la preuve juste sous les yeux. Et oui, MDI a du charisme et a entrainé beaucoup de gens avec lui, notamment dans Gnome, avant de les laisser dans la merde et de commencer un autre projet.
Même RMS y a cru. Lors de l'interview que KDE France a fait de lui à la linux expo 2003, il a dit qu'il regrettait d'avoir autant suivi Miguel et qu'il voulait maintenant se rapprocher plus de KDE.
> D-BUS est plus simple et n'a pas les objectifs de Corba et ne remplacera pas Bonobo.
Heureusement qu'il n'a pas les objectifs de Corba parce Corba est compètement indadapté aux besoins d'un protocole de communication inter-application de bureau. D-BUS a les objectifs de servir de protocole de comme entre les applis de bureau et le matériel. En ce sens, il va un poil plus loin que DCOP mais à l'époque ou DCOP a été concu, l'USB et le hotplug était de la science fiction donc on peut comprendre qu'ils n'ont pas abordé cette problèmatique de front.
D-BUS ne remplacera pas Bonobo en effet. Pour remplacer bonobo, il faut DCOP + KPart, c'est à dire un protocole de communication + une système de composant. Tout est déjà présent dans Gtk et dans Gnome pour faire un équivalent de KPart bcp plus léger que bonobo. En fait, en tant que simple programmeur KDE, j'ai réussi à faire un composant pour une application Gtk (gvim) en passant par des GtkSocketPlug. Donc un hacker Gnome, si il lui en prenait l'envie, serait probablement capable de cracher un système de composant léger en moins d'une semaine, le temps qu'il a fallu pour faire kpart. On attendra encore un ou deux ans pour que ça arrive, le temps qu'ils se désintoxiquent compètement de Corba et qu'ils oublient que KDE a déjà la solution.
> D-BUS c'est IPC avec un deamon.
Tout comme dcop. Un IPC et un demon. Pour ton info: http://developer.kde.org/documentation/library/kdeqt/dcop.html(...)
> Premièrement ton truc au-dessus est bourré de connerie.
Pour l'instant, on peut pas dire que tu as avancé un seul argument qui tienne la route pour me donner tort, au contraire.
> Deuxièmement MDI ne s'occupe plus de Gnome depuis la version 2.0.
De fait. C'est ce que je soulignais en disant que MDI change d'avis tous les deux ans et laisse les projets en plan.
MDI a ça pour lui que quand un projet commence à être dans la merde, il se barre en douce. Ca m'étonne pas qu'il soit plus dans Gnome. Il faudra plusieurs années à Gnome pour se remettre de sa présence mais le projet redécollera peut-être.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Je lui reproche de prendre en moyenne 2 ans pour s'apercevoir qu'il s'était complètement planté alors que la solution était la sous ses yeux et qu'il a refusé de l'utiliser. L'exemple de corba est tres parlant et ce n'est pas le seul. KDE a été hué et critiqué énormement pour leur absence de reflexion quand ils ont laché corba. Pourtant, n'importe qui prenant la peine d'analyser les raisons qui les ont pousser à rejeter Corba et à choisir une solution DCOP + KPart aurait vu que leurs raisons étaient tout à fait valides et que Gnome allait rencontrer les mêmes problèmes. Mais visiblement, _personne_ chez Gnome n'a pris la peine de faire ces démarches et bonobo reste une usine à gaz.
Pour ce qui est de la communication entre applications, Gnome reste très pauvre alors qu'on peut scripter n'importe quelle application KDE avec DCOP. D-BUS semble apporter une solution un peu plus riche et ô surprise, c'est un DCOP sans la dépendance X. Là encore, on frise les 4 ans pour s'apercevoir de l'interêt d'une technologie pourtant déjà mature dans un projet qu'ils ont sous les yeux. Si tu regardes les arguments qui sont utilisés pour D-BUS, ce sont les mêmes qui ont été avancé à l'époque où KDE 2 n'était même pas encore sorti.
Donc faire des erreurs, je veux bien. Mais être aussi aveugle, je pense qu'il faut vraiment y mettre de la mauvaise volonté. Apparemment, toute la clique Ximian lorgne maintenant beaucoup plus du côté de Microsoft que du côté de KDE.
KDE a aussi fait quelques erreurs mais la très grosse différence, c'est que des personnes qui réflechissaient objectivement (et pas en terme hype ou en lisant les press release de Microsoft) à tous les problèmes et les avantages d'une solution ont participé à la reflexion et qu'une bonne solution a été trouvée à chaque fois. La meilleure preuve, c'est qu'ils n'ont rien changé depuis 4 ans à dcop et kpart.
KDE a aussi choisi Corba mais s'est rendu compte de son erreur en moins d'un an. De plus, le projet a gardé la même ligne de conduite depuis sa création alors que Miguel n'a cessé de changer d'avis tous les deux ans comme je le soulignais là-haut. L'avantage, c'est que le projet a pu avancer de façon cohérente, alors que Gnome se disperse beaucoup et que beaucoup d'appli soi-disant Gnome sont en fait soit des applis Gtk, soit des applis Gnome 1, soit (pire) des applis Gtk 1. Bref, ca contraste beaucoup avec KDE et sa ligne de conduite claire.
[^] # Re: IHM et interfaces descriptives
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é à 4.
J'ai juste trouve deux trucs lourds, c'est de devoir casser des layout pour pouvoir ajouter un objet et le fait qu'on puisse pas creer des widgets customs heritant d'un widget connu.
[^] # 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é à 5.
Oui, c'est vrai. Il analyse bien les problemes. En revanche, il a le chic pour proposer la mauvaise solution.
Par exemple, si tu lis un des papier fondateurs de Gnome sur la critique des programmes unix et la complexite de faire travailler ensemble des outils graphiques, il a 100% raison.
Sa solution en revanche est toute pourrie: corba. On ne connais pas plus lourd, et les developpeurs sont encore en train de se battre avec la gestion de la destruction des resource partagees entre plusieurs processus.
A cote de ca, KDE a trouve la solution simple et efficace depuis 4 ans (KDE 2 est sorti en 2000) avec dcop et kpart. Mais MDI prefere croire que bonobo est la bonne approche et faire depenser un temps fou a ses developpeurs. Regardez la gueule du code pour gerer des objets corba, des exceptions et un IDL en C pour vous marrer un jour.
> On est nombreux à utiliser Gnome et evolution et à dire que mono nous permet enfin d'avoir un équivalent à C# et à ne pas passer pour des ploucs face à MS.
Desole, je ne fais pas partie des nombreux et je pense au contraire qu'avaler la couloeuvre mono toute crue vous fait passer pour des ploucs de chez Ms.
> Bref, il fait avancer les choses et concrètement.
Ah ouai ? Regardons un peu l'historique de MDI:
<<
- tiens, KDE c'est pas mal mais c'est du C++, c'est chiant les objets et tout ca et en plus Qt c'est QPL, c'est pas assez libre. Faisons Gnome en pur C et LGPL, ca pourra etre que mieux.
[ 2 ans plus tard ]
- putain, ce qu'il faudrait, c'est pouvoir echanger facilement des composants graphiques. On va utiliser Corba, ca a l'air hype. On va pas regarder tous les problemes qu'ont les developpeurs de KDE avec corba, c'est des mauvais, ils savent pas coder. Et puis de toute facon, Qt, c'est GPL, c'est trop libre. [1]
[2 ans plus tard]
- putain, corba et bonobo, c'est le bordel. C'est dingue ce que ca peut etre complique de gerer des resources entre plusieurs processus a temps de vie variable de facon asynchrone. [2] Et puis on passe quand meme vachement de temps a utiliser Corba. Il faut lire seulement un bouquin de 1000 pages pour ecrire un composant graphique en corba, j'ai peur qu'on soit a cote de notre objectif du partage facile de composant graphique entre application. En fait, il va nous falloir vachement de temps pour rendre tout ca simple et accessible en C.
[2 ans plus tard]
- putain, le C, c'est pas top. En fait, pour faire des classes et des objets avec de l'heritage, des methodes virtuels et du typage fort, le C est pas adapte. Je sais pas pourquoi on y a pas pense plus tot mais il nous faudrait un langage oriente objet. Un truc genre C++ mais on aurait l'air con si on recommendait C++ apres avoir attire les developpeurs sur Gnome en leur diisant qu'ils feraient du C pur. Donc faudrait autre chose. On pourrait prendre le truc de Microsoft, C#. C'est hyper hype, ca sera bon pour nous.
[2 ans plus tard]
- putain, c'est dingue ce qu'on est efficace avec un langage objet. Vraiment, vous etes des loser en C, venez faire du C# avec Mono et Microsoft, c'est bien plus cool. Pour Gnome qui est ecrit en C, ben demerdez-vous, moi maintenant, je fais du C#.
[Dans 2 ans]
- putain, c'est dingue, Microsoft nous empeche de continuer Mono a cause de ses brevets, ses droits d'auteurs, le DMCA, ses copyrights sur les API et la pression sur les clients qui voudraient l'utiliser. Je sais pas comment on a fait pour ne pas le voir venir. Mais bon, j'ai la solution, on va lancer un nouveau projet qui n'aura rien a voir avec Mono et Gnome mais qui resoudra tous les problemes. Ah, pour les gens qui ont cru en moi et on fait du Gnome en C#, demerdez-vous. Moi, je suis sur mon nouveau projet.
>>
> Le logiciel libre, c'est la compétition. Les nazes sont rapidement repérés et virés.
Apparemment, les nazes ne sont pas si vites reperes puisque certains croient encore que MDI peut avoir des bonnes idees.
> MDI est toujours la
Dans Gnome ? Ah, non, il est plus dans Gnome. Mais oui, il est toujours vivant et il raconte toujours son lot de connerie, et tout le monde le croit encore.
[1]: De fait, apres le nombreux problemes lie a la complexite de Corba, l'equipe KDE a cree DCOP et KPart, qui rendent les services initialement prevu, mais sont beaucopu plus stables, tiennent chacun dans moins de 1000 lignes de code, ont ete ecrits en deux jours, sont rapides a charger et facile a controller. By by corba.
[2]: tire d'un Gnome Fondation summary. Dommage, j'ai perdu la reference mais qu'est ce que je me suis marre a le lisant. On aurait dit un mail de la liste de dev de KDE 4 ans plus tot. C'est des rapides chez Gnome pour comprendre les problemes.
[^] # 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é à 9.
MDI est bien parti pour etre le suiveur du siecle. Apres avoir lance Gnome pour suivre KDE, bonobo pour suivre Corba, Evolution pour suivre Outolook, mono pour suivre les pratiques de developpement moderne (vous savez, le truc ou pour ecrire un widget dans une appli, il n'y a pas besoin de 70 lignes de code C indigeste bourre de macro), on a maintenant droit a XAML. C'est pas Novell qui aurait du racheter Ximian, c'est Microsoft. Il se seraient sentis chez eux.
Bravo, vive l'innovation.
Comme par hasard, les deux gus se gardent bien d'aller regarder ce qui se fait du cote de KDE (des fois qu'il y aurait deja la solution) et preferent lorgner chez Microsoft. Bel esprit logiciel libre. On peut dire que la rivalite KDE / Gnome est loin d'etre inexistante chez certains. Vraiment, quand je vois qu'on peut preferer des solutions microsoft comme Mono avec tout le bagage de risque que ca comporte, alors qu'il y a des solutions eprouvees pour faire la meme chose du cote de KDE, ca me debecte.
Citons chez KDE:
- Qt Designer: 10 fois plus utilisable que Glade, permet de cracher une interface graphique en XML en 10 minutes. D'ailleurs, il relit les fichiers Glade. Bien que peu utilise, il y a la possibilite de livrer un fichier descriptif xml avec une application pour que le fichier soit charge dynamiquement et que l'apparence de l'application soit modifiable dynamiquement.
- Kommander: on genere une interface en s'appuyant sur Qt Designer et on fabrique un front-end en 10 minutes.
- XML Action: depuis KDE 2, l'organisation des menu et barres d'outils se fait via un fichier XML qu'on peut modifire dynamiquement
- KConfigXt (http://developer.kde.org/documentation/tutorials/kconfigxt/kconfigx(...) ) qui permet de generer tres facilement des dialogues de configuration a partir d'un simple fichier XML.
Et il y en a d'autres qui arrivent.
De ce que j'ai lu sur XAML, ca ressemble a ce qu'on peut faire en Visual Basic (associer un evenement sur un controle a une fonction executee) mais en XML. Ca ne resoud pas deux problemes fondamentaux:
- la programmation par evenement devient vite tres lourde. L'approche Gtk/Qt avec des signaux et des slots est beaucoup plus puissante
- une bonne interface graphique ne peut pas etre generee automatiqueement. Une bonne interface graphique, ca se travaille et ca prend du temps. Donc XAML ne pourra etre utilise que pour des interfaces graphiques de qualite moyenne. Pour arriver a un truc bien, il faudra passer autant de temps que avec Qt Designer.
Donc moi, je n'y vois qu'un n-ieme campagne de Microsoft reprenant des idees presentent ailleurs depuis des milliers d'annees et faisant croire que c'est un concept revolutionnaire.
[^] # Re: Testez OpenOffice 1.1.1rc
Posté par Philippe F (site web personnel) . En réponse à la dépêche Testez OpenOffice 1.1.1rc. Évalué à 1.
[^] # Re: Linux dans le Magazine "Capital" du mois de Mars 2004
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linux dans le Magazine "Capital" du mois de Mars 2004. Évalué à 5.
Donc au lieu de raler, prend ta plume.
[^] # Re: Y : un remplaçant pour X ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Y : un remplaçant pour X ?. Évalué à 1.
La force du logiciel libre, c'est la diversite de l'ecosysteme. Je fais partie de ceux qui pestent a cause de la separation des efforts, mais c'est ca aussi qui permet d'essayer des idees differentes et de proposer des solutions innovantes.
Il y a toujours deux approches possibles: la cathedrale ou tu fais tes plans et avec ton equipe, tu construis ton bazar. Tu sais ou tu vas et si tu t'es pas goure dans tes plans, ca marche. Sauf si t'avait pas vu au depart quelques subtilite qu'on ne rencontre qu'un milieu de projet.
Le bazar: tout le monde fait n'importe quoi et a la fin, ceux qui ont survecu et qui apportent qqch emergent. Ca prend plus de temps mais le resultat est plus robuste. Et surtout, il y a plusieurs voies qui sont envisagees.
[^] # Re: Y : un remplaçant pour X ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Y : un remplaçant pour X ?. Évalué à 2.
En ce qui me concerne, je crois qu'aucun projet de serveur graphique ne pourra s'imposer sans une compabilite tres forte avec X au niveau de la base existante. Coup de bol, c'est prevu. M'enfin, je reste tres tres tres sceptique et je crois bcp plus a la re-ecriture de la xlib.
[^] # Re: Testez OpenOffice 1.1.1rc
Posté par Philippe F (site web personnel) . En réponse à la dépêche Testez OpenOffice 1.1.1rc. Évalué à 1.
Ca, c'est vraiment un probleme. Sous windows, des que je fais tourner un firewall, un antivirus, oo avec plusieurs documents, firefox et thunderbird, ma machine commence tres tres nettement a manquer de RAM. C'est vrai, je n'ai "que" 256 Mo mais quand meme.
A cote, word ou excel ouvrent les documents tres tres rapidement, le lancement de IE est presque instantane.
> - certaines fonctionnalités sont loin d'être instinctives (essayez de mettre une page du milieu d'un rapport en paysage)
C'est bien explique et dans l'aide et dans les tutoriaux. Au contraire, une fois que tu as compris l'esprit, je trouve ca beaucoup plus instinctif et facile a utiliser.
> - l'aide est encore très limitée par rapport à celle d'Office
Moi je trouve au contraire qu'elle est beaucoup plus complete, beaucoup mieux redigee et beaucoup plus accessible. C'est grace a elle que je suis beaucoup plus productif sous OO que sous MsO.
> - il manque de nombreux modèles de documents (pour les présentations, les rapports...)
C'est relativement facile de se faire son modele donc ce ne me gene pas. La premiere fois, tu y passes une heure et apres c'est bon. De toute facon, un modele standard ne m'a jamais convenu et il a toujours fallu que je le modifie. La difference avec msO, c'est que sous OO, cette operation a ete extremement simple.
> - il n'y à pas de correcteur d'orthographe / grammaire du niveau de celui de Office (on en ai assez loin)
Le correcteur orthographique qu'on peut recuperer sur le site me suffit.
Bref, en dehors des gros problemes de lenteur, moi je trouve vraiment la suite excellente. Et avec la generation du pdf, il y a pas photo. Surtout quand on pense aux recents problemes des documents words...
[^] # Re: Statut de BEOS
Posté par Philippe F (site web personnel) . En réponse à la dépêche BlueEyedOS devient LGPL. Évalué à 1.
[^] # Re: Statut de BEOS
Posté par Philippe F (site web personnel) . En réponse à la dépêche BlueEyedOS devient LGPL. Évalué à 1.
donc c'est comme XFRee
> un gestionnaire de fenêtre
Comme kwin ou metacity ou les 50 autres
> un gestionnaire de bureau.
Comme KDE ou Gnome.
Sachant qu'en plus, certains projets se basent sur XFree, il ne reste plus grand chose d'original.
Ca rejoint mon post plus haut. Ce qui faisait la specificite de BeOs, c'est son coeur et mettre ce coeur sur du Linux, ca veut dire perdre les specificites de BeOs et le mettre au meme niveau que Window Maker ou KDE.
[^] # Re: BlueEyedOS devient LGPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche BlueEyedOS devient LGPL. Évalué à 3.
Mais le noyau linux convient-il reellement ? Pour faire du bon multimedia, on doit s'approcher d'un noyau temps-reel qui doit fournir des garanties de delai pour toutes les applications video ou sonores. Or le noyau linux a un scheduler classique et si la pre-emption cote utilisateur permet de gagner un peu en performance, il ne me semble pas que ce soit un vrai noyau oriente multimedia. Bien sur, sur une bete de course, il repondra aussi aux contraintes du multimedia mais qu'en est-il des perfs d'une machine moyenne ?
Je ne connais pas grand chose a BeOs donc corrigez-moi si je dis une connerie mais ce que j'en avais compris, c'est que c'etait un OS avec quelques services innovants ou originaux presents dans l'OS : micro-noyau, oriente multi-media, systeme de fichier en base de donees, ...
En refaisant l'API BeOS avec du Linux + XFree, on refait certe le look BeOS mais on perd le "feel", ce qui faisait l'atout de cet OS. Bref, ca n'a pas plus d'interet que KDE ou Gnome.
Qq'un de plus verse sur le sujet pourrait-il confirmer ou infirmer ?
[^] # Re: J'ai switché pour GNU/Linux (et pourtant je suis nul)
Posté par Philippe F (site web personnel) . En réponse à la dépêche J'ai switché pour GNU/Linux (et pourtant je suis nul). Évalué à 2.
Il montre aussi le point de vue d'un type qui n'y connais rien au depart , qu'on a un peu tendance a oublier. La premiere fois que tu modifies ton lilo.conf a la main, ca fait flipper. Mais apres, c'est que du bonheur.
[^] # Re: Gentoo 2004.0
Posté par Philippe F (site web personnel) . En réponse à la dépêche Gentoo 2004.0. Évalué à -1.
Je trouve que cela a aussi un cote mauvais esprit pour gentoo. Genre on est une distribution communautaire ou tout le monde est le bienvenu mais pour participer vous devez nous abandonner votre travail.
Sans compter que niveau legal, gentoo est loin d'etre clair. Pourquoi c'est Gentoo Inc. (une societe commerciale) et pas une assoce a but non lucratif qui recupere les copyright ? La possibilite que gentoo recupere le travail de ses contributeurs pour en faire une version proprio et se faire du fric ne me parait pas negligeable. J'avais entendu Daniel Robbins discuter avec un developpeur au Fosdem 2003 et il disait qu'il contactait des boites de jeu voulant sortir des jeux sous linux pour les faire passer a gentoo.
Bref, je suis un utilisateur de gentoo relativement heureux sur le plan technique mais decu par ces aspects. Gentoo traine quelques casseroles pour l'instant et j'espere qu'il n'y a pas de cadavre au fond du jardin.
[^] # Re: décentralisation
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GNU Arch/TLA 1.2. Évalué à 2.
Cela dit, un gros avantage de subversion, c'est sa simplicite. J'ai rien eu a apprendre pour passer de cvs a subversion et ca c'est appreciable. Mais j'aimerai bien pouvoir faire ce qui vient d'etre decrit.
Notamment, il y a le cas ou qq'un veut faire un fork d'un projet et ou il est quand meme interessant de recuperer tout l'arbre de version du premier projet.