Christophe Fergeau a écrit 1255 commentaires

GConf utilise plusieurs fichiers par application (via GConf), GNOME est donc plus dans la philosophie Unix que KDE?
Accessoirement, faire un backend pour GConf qui crée un unique fichier par appli (les préférences de chaque appli sont rangées dans ~/.gconf/apps/nom_de_l'appli pour l'instant), ça doit prendre un après midi je pense...
C'est vrai que GConf est un système de config centralisé et partagé par toutes les applis, donc vu de loin si on réfléchit pas trop, on dit "ah ouais, comme windows".
Mais bon, à ce moment là, linux qui est un noyau permettant d'abstraire le matériel et de faire tourner plusieurs processus en même temps, et qui propose aussi une interface graphique en mode fenêtré, le linux donc est "comme windows" aussi...

Et comme d'hab, on ne parle pas des dizaines de mecs qui bossent sur QT à plein temps... Je sais pas comment c'est dans KDE, mais pour GNOME, GTK ça représente plus de la moitié des api proposées...

Deux remarques plus ou moins liées à tout ça :
* avec ORBit, une fois que le composant est instancié (aucune idée de la lourdeur de la chose), pour un composant "in-proc" (c'est à dire un .so qui est chargé dans l'exécutable en cours d'exécution), le coût d'appel d'une méthode est à peu près aussi coûteux que l'appel d'une méthode virtuelle en C++ (il suffit de regarder les stub/skels générés par ORBit pour s'en convaincre)
* dans les trucs que tu énumères, il y a en fait à mes yeux un seul gros problème avec ORBit/bonobo, c'est
« le tout doit etre facile a apprendre de facon a ce que les developpeurs qui travaillent sur leur temps libre puisse facilement ecrire des composants »
Il manque à ORBit des outils permettant d'interfacer tout ça super facilement avec des gobjects, et c'est ça un des plus gros problèmes à l'heure actuelle à mon avis. Le reste de ton discours oscille entre des problèmes plus ou moins importants et des propos plus ou moins de mauvaise foi/fud-esque.

Oui mais c'est chiant de définir tous les accesseurs manuellement, c'est pour ça que c'est bien si le langage supporte les attributs pour t'éviter de taper tout ça ;)

Par "supporter les attributs", je veux dire la possibilité de désigner certaines variables membres d'un objet comme accessible de l'extérieur en lecture et/ou en écriture. En C++ tu peux les marquer comme publiques, mais tu peux pas en déclarer en lecture ou écriture seule. En gros un attribut = toute variable membre pour laquelle t'as besoin de fonctions get/set
En ruby, c'est
class Song
attr_reader :name, :artist, :duration

par ex

>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

Avant aujourd'hui, chaque fois que j'entendais parler de l'abandon de CORBA par KDE, la raison avancée était que l'ORB utilisée par KDE était super lente, d'où abandon, suivi d'un "tiens, réinventons notre truc à nous au lieu d'utiliser ce qui existe déjà"

>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.

Le choix du C++ pour faire un truc comme QT ou GTK+ est aussi complètement stupide vu que le langage ne support pas les attributs ou les signaux nativement.
(à ne pas prendre littéralement non plus, j'en ai strictement rien à foutre que qt utilise du C++ ou ce qui leur plaît, c'est juste pour souligner que sous entendre que kde a choisi un langage parfaitement adapté en prenant le C++ c'est un peu du foutage de gueule)

On t'as vendu du mauvais humour, tu devrais te faire rembourser ;)

« 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. »

Tu veux dire Mono ou XAML là ? Si tu voulais vraiment dire mono, le reste de ton post veut pas dire grand chose...

J'aime bien les mecs qui affirment haut et fort que gnome utilisera mono.
Qques développeurs aimeraient apparemment s'en servir mais *rien* n'est décidé, mono n'est même pas dans la "gnome developer platform", et à mon avis si qqu'un propose de l'ajouter, ça va flamer sec.
A mon avis on va voir qques applis en c# matures pour gnome 2.8 ou gnome 2.10, mais le temps que du c# apparaisse au coeur du projet est encore loin à mon avis.

La version finale sera 100 fois plus évoluées et aura besoin de 2 fois plus de mémoire, c'est ça ? ;)

Allez y les gars, continuez à critiquer les choix des devs de epiphany et galeon sans avoir aucune idée de de dont vous parler, c'est la meilleure façon de faire avancer les choses.
Ou alors vous pouvez aller lire http://galeon.sourceforge.net/links/history.php(...) , faire marcher un peu vos cerveaux et on en reparle.

En fait la biblio de gravure a pas grand chose à voir avec gnome, elle a été démarré par qques personnes dans leur coin, et une personne voulant faire un logiciel de gravure pour gnome a décidé qu'il voulait l'utiliser.
Il faut pas perdre de vue qu'il n'y a pas à ma connaissance de bibliothèque (libre qui plus est) sous linux/unix pour faire tout ce qui est gravure de cd (tous les trucs de gravure sont des frontends à cdrecord/cdrdao)

En gros, une fenêtre et l'objet "dossier" sur ton disque dur correspondent au même objet. Donc dans une même fenêtre, ça ne fait aucun sens d'afficher le contenu de dossier différents, puisque la fenêtre c'est ton dossier. De même, si tu as ouvert une fenêtre d'un dossier dans un coin, chaque fois que tu accèdes à ce dossier, c'est la fenêtre déjà ouverte qui est réutilsée.

Moi epiphany me convient bien.

(on s'en fout je sais)

Mais peut être que MS te paie pour que tu fasses semblant de ne pas savoir et de donner ton avis, alors que tu sais tout et que ton job est juste de traîne sur linuxfr pour faire croire que MS fait rien de mal.

Tu es démasqué ;)

Ils sont peut etre pas complètement cons non plus, s'ils veulent filer de la thune en douce, ils vont pas dire à sco de foutre une ligne "argent filée par MS: 86 millions" dans leurs comptes sachant que ces comptes seront rendus publics

Ouais, enfin faut pas non plus se leurrer et tomber dans le syndrome de "microsoft c'est une grosse boite, mais elle est pas comme les autres, elle elle est gentille et respecte les règles du jeu, elle ne fait pas de coup bas/de trucs très discutables à ses concurrents"
Donc ça parait normal de rester vigilant...

> et aide l'utilisateur à comprendre le système d'exploitation.

Ouais, c'est clair, pendant les compils il faut bien s'occuper.

GNOME 2.5 c'est une version de développement, c'est pour ça que c'est pas dans la debian...

Oui, je suis un peu surpris par les commentaires dans les news sur subversion 1.0 ou arch 1.2, y a aucun des deux threads qu'a dégénéré en troll, félicitations à tous les participants ;)

Ouais...
Y a un tutorial qui a l'air très complet (même si je l'ai pas vraiment lu), toutes les commandes ont une aide, mais y en a un paquet, et c'est globalement très différent de CVS, au début t'es tout perdu :-/
http://www.rhythmbox.org/development.html(...) présente de façon assez succinte à quoi ressemble une utilisation basique de arch pour un projet.

Avec arch, tu aurais plutot un repository sur ta machine principale, un repository sur ton portable, qui serait probablement crée à partir du repository de ta machine principale (si t'as qu'un portable, ça simplifie un peu, t'as juste un repository et puis voilà).
Pour que l'autre développeur puisse participer, tu publierais ton archive principale sur un site public en lecture seule. L'autre développeur peut alors créer une branche à partir de cette archive principale et travailler dessus.
Ensuite, pour intégrer tous les changements entre ton portable, ta machine principale et les changements de l'autre développeur, le plus simple c'est d'avoir les 3 archives publiées qqpart sur le net (ou d'avoir un accés ssh ou webdav privé vers ces machines), et arch est alors capable de fusionner les changements en provenance de n'importe quelle branche vers n'importe quelle autre branche. Tu peux donc récupérer tous les changements faits sur ton portable et par l'autre développeur et les intégrer dans ton repository local facilement.

J'aimerais bien que gnome et freedesktop passent à qqchose de plus puissant que cvs ;) Un support des changesets me parait maintenant quasiment indispensable :)

A la base, subversion et bitkeeper ont pas grand chose à voir
subversion est basé sur un modèle centralisé, où il y a un dépôt central alors que bitkeeper et arch sont basés sur un modèle distribué, où il n'y a pas nécessairement de dépôt central, mais où n'importe qui peut créer des branches locales, les publier, faire des fusions avec des branches situées à d'autres endroits sur le réseau.
Il y a effectivement moyen de faire ça avec subversion et l'extension qui va bien si je me rappelle bien la news au sujet de la sortie de subversion 1.0, mais c'est une surcouche, et on est peut être limité par le modèle centralisé sous jacent, j'en sais strictmenet rien, j'ai pas essayé.