Philippe F a écrit 2204 commentaires

Ca, c'est du cassage en regle !

En dehors de ses performances, est-ce que bazaar sait faire des choses mieux que les autres. Quid de hg, j'avais jamais entendu parle. C'est stable ?

Alors que au moins, quand on parle de Gnome ou KDE, on reste vraiment longtemp dans le coeur du sujet !

A la lecture du forum, il semble que la principale avancee de KompoZer soit une suite de correction de bug. Est-ce que ca sort de "la direction" de NVu ? Il sembe qu'un certain nombre d'utilisateurs se plaignent de ces bugs.

La notion de maintenance fait quand meme partie de tout developpement logiciel, meme libre. Par exemple, bien que les deveuloppeurs KDE soient occupes a preparer KDE 4, ils ont quand meme pris la peine de sortir plusieurs versions de maintenance de KDE 3.5 et parfois meme de KDE 3.4. On peut dire la meme chose de Gnome, du kernel, etc.

Une attitude qui serait possible, c'est de reconnaitre que KompoZer appporte quelque chose a la base NVu 1.0 et aux utilisateurs de NVu 1.0 et d'en faire NVu 1.0.X ou 1.1 en attendant la version supreme qui prendra le relai.

En tant que developpeur logiciel, je mesure bien le travail que represente la maintenance d'un logciel. La, il y a un mec qui se propose pour faire tous le boulot penible de correction de vieux bug et il se fait jeter. Ben je trouve ca dommage pour les utilisateurs de NVu.

Dans ton blog, tu ecris aussi qu'il n'a pas contacte Linspire, ce qui est faux comme on le constate dans les commentaires (non affiches en page principale). Je pense qu'il serait correct de ta part de mettre une note dans ton blog precisant qu'il avait contacte Linspire.

winmerge

Bon, ca marche que sous windows, mais c'est opensource :-)

Tout a fait. Alors que le bon vieux format du .ini a la windows reste lui indetrone !

> Le fait est que KDE ne propose pas grand chose.

Plus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.

Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.

> M'enfin, Gnome a fait au moins cinq fois plus de propositions.

Je m'eleve en faux contre cette proposition. Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.

Une grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.

> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,

C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.

Gstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien (note que c'est le comportement a l'heure actuelle).

La solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.

Phonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.

As tu envisage que au moment ou j'ai ecrit ce journal, Gnome n'etait pas liste dans la page web ? J'aurai du faire un screenshot, puisque ma parole est mise en doute si facilement.

Et puis excuse moi, je n'avais pas realise que les gens qui lisent linuxfr etaient des managers presses.

<<
- le site a eu un légé problème technique rendant les statistiques de gnome invisible mais ca ne t'empêche pas de pondre un roman pour ... rien ;
>>

Ben, qu'un projet aussi important que Gnome disparaisse d'un moteur de verification de vulnerabilites et ce justement aux alentours d'une release, ca demande un minimum d'investigation, tu ne trouves pas ? KDE aurait disparu, je me serai pose les memes questions. Sauf que sur KDE, je sais ou trouver les reponses, alors que sur Gnome, je demande.

<<
- tu n'as rien a dire de concret dans ta croisade contre gnome, par contre tu le fais savoir de façon hautement ridicule.
>>

De fait, en ce moment, Gnome fait des trucs vraiment pas mal. Je n'ai pas essaye depuis longtemp mais la presentation d'un Gnomeux a la derniere linuxexpo m'avait plutot laisse sur le cul. Apres, les qualites d'un desktop ne se voient pas que a la premiere utilisation mais sur la duree.

Sinon, contrairement a ce que certains pensent, j'aime plutot bien le projet Gnome. Ce qui m'agace, ce sont ceux qui le defendent aveuglement, sans reconnatire ses faiblesses [1]. Par exemple quand je lis comme hier soir que KDE ne fait rien sur freedesktop alors que c'est totalement faux (et il suffit de lire les archives de freedesktop pour s'en convaincre), ca me herisse.

J'essaye a ma facon de retablir la verite historique. Et je ne me contente pas d'avoir une opinion sorti de mon trou du cul. J"ai ecrit des programmes en Gtk, j'ai compare des programmes Gtk et Qt, j'ai suivi de plus ou moins loin l'activite de certains projets Gnome, j'ai lu le tutorial bonobo de meme que celui de kpart pour faire la comparaison, j'ai discute avec des gens bien informes sur des problemes precis comme les problemes des bindings.

[1] Note que ne pas reconnaitres ses propres faiblesses, c'est perdre une occasion de les corriger.

<< Il y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça. >>

C'est tout a fait vrai. Mais pour une implementation. Pour une specification qui se veut commune a plusieurs bureaux en revanche, la concertation est fondamentale. Et Tango est justement un projet avec un but d'unification des icones pour plusieurs bureaux.

cf par exemple :
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
The purpose
of the Tango project is not only the icon theme. The purpose is to work
towards unifying the visual aspects of all the desktops.
>>

<< Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars". >>

Ah oui ? Au contraire, les gens de KDE par exemple ont dit "c'est ininteressant pour KDE, on n'adoptera jamais votre truc mais continuez les gars".

http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)

Concernant XFCE :

http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
Nobody said that Xfce will ship the Tango icon theme. Brain just said
that he wants to "join as Xfce representative". We'll discuss that issue
when the time arrives (which don't seem to be anytime soon).
>>


<< KDE ne fout pratiquement pour freedesktop >>

Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.

Par exemple si on prend les archives du mois d'aout 2006 :
http://lists.freedesktop.org/archives/xdg/2006-August/author(...)

Tu noteras des messages de Waldo Bastian, Aaron Seigo et Lubos Lunak. Il y a beaucoup plus de developpeurs KDE que cela qui lisent freedkestop mais ils n'ont pas toujours quelque chose a dire.

Tu peux noter le travail extremement actif de Waldo Bastian sur la stabilisations d'un certain nombre de specifications, en ce moment la spec qui decrit les fichiers .desktop

On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.

<<
Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard. Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
>>

C'est fort parce que tu reussis a etre tout a fait d'accord avec ce que je pense tout en etant persuade que je pense le contraire. Relis mon post calmement et peut-etre que ce sera plus clair. Peut-etre me suis-je mal exprime ?. J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.

Freedesktop est au contraire un endroit de concertation et j'ai cite de nombreuses specs freedesktop sur lesquelles la concertation a eu lieu et a donne des resultats interessants.

Tango n'a pas suivi ce processus fondamental de concertation et a cause de cela, restera un projet dedie a Gnome. Le coeur de Tango en lui-meme me parait tout a fait interessant mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.

<<
Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
>>

Comme DCOP ?

Quand tu as plus de 500 vulnerabilites, ca commence a etre beaucoup de travail d'arriver a 0. Il me semble me souvenir que Gnome partait de loin au debut. Et maintenant, personne ne peut plus me contredire (gniark gniark gniark).

C'est la rentree, je recommence mon entrainement intensif.

Plus serieusement, personne ne sait pourquoi Gnome est sorti ? Ca m'etonne quand meme. J'espere vraiment qu'aucune des raisons que j'avance n'est veridique !!

C'etait sympa en plus, on pouvait comparer le nombre de lignes de Gnome et de KDE. Ca ouvrait la voie a plein de nouveaux trolls.

Je ne suis pas trop d'accord avec toi. Il y a certains developpeurs dans Gnome qui ont une attitude vis a vis de KDE qu'on peut qualifier de detestable mais beaucoup ont une attitude tres constructive. Il suffit d'ignorer les geneurs et d'avancer avec les gens qui veulent avancer.

Dbus n'a pas ete impose a KDE. Dbus a des avantages sur DCOP : pas de dependance a X, pas de dependance a Qt. Il aurait ete possible de re-ecrire DCOP pour en faire le DBUS actuel mais le fait est que personne ne l'a fait. Comme souvent en logiciel libre, c'est celui qui fait le travail qui decide et personne n'a fait le travail pour DCOP.

Globalement, DBUS est une belle histoire. Il faut savoir avancer en mettant de cote son NIH syndrome. DBUS a un gros avantage par raport a DCOP: il est reconnu au sein de Gnome. Ca veut dire que dans le mesure ou KDE ne perd pas en fonctionnalite vis a vis de DCOP, c'est une victoire pour le desktop linux : on va pouvoir resoudre plein de probleme pa DBUS et permettre aux deux bureaux majeurs d'en profiter : notification de material branche, baterie faible, etc etc.

La seule chose qui m'agace, c'est les enthousiastes de Gnome qui s'extasient sur les possibilites de DBUS et presentent cela comme une revolution lancee par Gnome alors meme que la plupart desdites fonctionnalites sont presentes depuis 6 ans dans KDE.

Un petit mot sur tango. Le but est louable, mais la methode est completement a l'inverse de la facon dont doit se developper une specification qui pretend etre adoptee par plusieurs bureaux.

En gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee, a developpe tango sans aucune concertation avec des autres desktop et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau devaient adopter. C'est vraiment l'oppose des buts et du principe de freedesktop.

Il y a un certain nombre de raison pour KDE de ne pas adopter tango. Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande, donc ils n'ont pas leur mot a dire sur le "standard". Ensuite, Gnome et KDE ont un style d'icone qui est different. Tango utilise le style Gnome qui ne s'integre pas du tout dans l'historique de KDE. Enfin, KDE a son propre style d'icone tres complet et n'a pas besoin de Tango.

Je pense que le projet en soi est interressant mais pas pour plusieurs desktops.

A contrario, on peut citer un certain nombre de specifications de freedesktop qui ont ete developpees en _cooperation_ avec les differents bureaux, et qui sont un succes :
- placement des icones sur le systeme de fichier
- organistion des themes sur le systeme de fichier
- contenu des fichiers .desktop
- utilisation de dbus
- notification dans la barre des taches
- applets dans la barre des taches

A noter que tango n'est pas le seul projet a avoir fonctionner comme cela. On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc. Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.

Tango est un tout petit peu different de cette situation puisque c'est une specification deja adoptee au sein de Gnome. Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).


Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.

L'appel pour akademy 2007 est en cours, il suffit qu'un des organisateurs "postule" pour proposer d'utiliser les RMLL.

Sinon, plusieurs developpeurs de Gnome sont invites a akademy, de meme que des developpeurs KDE sont invites au Guadec. Donc les discussions ont bien lieu.

> Les layouts par défaut sont soit trop limités, soit trop complexes à utiliser (GridBa gLayout, Grrr). Mais rien ne t'empêche de développer ton propre layout

Rien ne m'empeche non plus de developper un toolkit graphique complet pour remplacer Qt, Gtk, Swing en une seule fois. Sauf que je prefere me concentrer sur la logique de mon application et que je trouve que ce travail revient plutot au developpeur du toolkit graphique.

Le fait que les layouts soient mal geres veut dire que le programmeur va passer beaucoup de temps a resoudre un probleme qui n'a rien a voir avec l'application qu'il developpe alors qu'il pourrait etre en train de corriger des bugs ou ajouter des fonctionnalites.

Je ne connais pas swing, mais dire dans la meme phrase que les layouts sous swings sont pourris mais que swing c'est bien me parait un peu tire par les cheveux.

Une application graphique, c'est avant tout un ensemble de briques graphiques a organiser. Et de nos jours, on a les parametres suivants qui sont variables :
- les traductions peuvent allonger ou racourcir les dialogues en permanence
- les gens ont des resolutions d'affichage hautement variable : entre le commercial avec son portable 12 pouces et le geek avec son 3500 x 4600, il faut s'adapter.

Donc les layouts sont quand meme un element important de la conception graphique de nos jours.

Pour l'instant, je trouve le discours des defenseurs de swing plutot desagreable. En gros, soit le programmeur est assez intelligent pour comprendre comment swing marche, soit il ferait mieux de retourner a son visual basic. Ca me fait penser aux defenseurs des MFCs qui disent que les MFCs sont simples et faciles a utiliser, mais qu'il faut 5 ans pour apprendre a bien s'en servir.

Trolltech a propose une approche de la programmation graphique qui est facile. Ce n'est pas une tare d'etre facile a utiliser, et ce n'est pas parce que Microsoft a fait rimer facilite et simplicite avec truc crade et inutilisable en gros deploiement que c'est une loi immuable.

Qt possede a mon sens l'avantage d'etre agreable a utiliser par des experts et par des debutants. Les debutants sont contents d'arriver rapidement a des resultats et les experts ne se sentent pas contraints par le framework mais peuvent au contraire laisser libre cours a leur creativite.

Pour revenir a l'histoire des layout, sous Qt, on peut par exemple laisser un expert en ergonomie travailler sur l'interface avec Qt Designer pendant que le programmeur travaille sur la logique, et cela sans se perturber l'un l'autre. La gestion des layouts est donc accessible a des non-techos.

Dans toutes les applications graphiques sur lesquelles j'ai travaille avec Qt, ce qui m'a le plus plu, c'est que comme la partie graphique est simple a mettre en place, on peut vraiment se concentrer sur la logique de l'application.

Il y a d'autres forks relativement reussis :
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore

- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.

Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.

icescream a ete developpe par un gourou KDE (Stephan Kulow) et marche super bien. Pas une seule reuninon KDE ou les developpeurs ne commencent pas par deployer du icescream partout. Je suis surpris de ne pas le voir cite.

La page web: http://en.opensuse.org/Icecream
(l'url du commentaire plus haut a une parenthese en trop)

Petite copie de la partie interessante :
============================================
I use distcc, why should I change?

If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:

* you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
* you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
* you don't know what machines will be on-line at compile time.
* most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
* you like nice compile monitors :)
============================================

Je ne sais pas pour vous, mais la mise a disposition gratuite d'un service autrefoir payent, ce que ca m'insipre, c'est que le service payant n'a pas marche et qu'ils essaient de relancer la machine.

Ca fait longtemp qu'on entend plus parler du mandrake club, est-ce que ca tourne toujours ?

La news, c'est pour dire que beagle est capable d'analyser les messages et les contacts de thunderbird ?

Baleze, vraiment vraiment. Les messages sont au format mbox, qui est plus que trivial a analyser (je bourre tous les messages en texte dans un fichier), surtout quand on a fait le format maildir auparavant (un message par fichier texte dans un repertoire). Et les contacts sont au format vcard (du texte encore). Donc en fait, beagle est maintenant capable d'analyser des fichiers textes. Moi, ca m'impressionne :-)

Bon, plaisanterie a part, c'est sympa de voir ce projet avancer et j'imagine qu'il y a plus que l'indexation de fichier texte dans l'integration thunderbird. Mais ca ne ressort pas trop dans la news.

Moi je dis, ils devraient se mettre a topcoder. Ils peuvent gagner de l'argent toutes les semaines et c'est super stimulant.

http://www.topcoder.com/tc

En fait, ce serait pas plus simple d'utilier Qt Designer avec une bonne transformation XSLT ? Ou bien carrement de faire un gtk-uic qui transforme la description xml de Qt Designer en implemntaion Gtk ? 99% des widgets Qt sont presents sous Gtk donc ca devrait pas etre si difficile.

Qt Designer est en GPL, ce serait pas difficile de le faire evoluer pour supporter du Gtk. Il fait deja l'import des fichiers glade de la version precedente :-)

Sans oublier la fonctionnalite de base qui manque cruellement a Sunbird: popup 1/4 heure avant le debut de la reunion, ou insertion dans l'agenda quasi automatique depuis le client mail. Ou encore possibilite pour des externes (secretaire, collegue) de te caser une reunion dans ton agenda, etc etc.

Pour ma boite, je cherchais un client windows libre quelconque mais fonctionnel (== pas une interface web) pour fonctionner avec un serveur libre quelconque sous Linux. La conclusion a ete que le plus fonctionnel etait probablement outlook avec un truc genre kolab. Plutot deprimant. Le probleme notamment, c'est que charger oulook + thunderbird en memoire, c'est vraiment du gachis de resources. Vivement kontact sous windows.

En fait, la conclusion de notre analyse a surtout ete qu'on manquait cruellement de standard en matiere de gestion d'agenda. Il y a bien les trucs genre iCal mais c'est pour formatter les inforamations sur un rendez-vous, pas pour definir la facon de se connecter a un serveur.

Tant qu'on aura pas un "Calendaring Transfer Protocol", les developpements auront du mal a se se focaliser sur un client de bonne qualite et on restera avec des solutions dispersees et de qualite moyenne voire pitoyables.

Justement parce que les fonctionnalites sont equivalentes, ce n'est pas possible d'envisager une convergence. Ca voudrait dire que l'un des deux projets doit abandonner son moteur, ce qui est inenvisageable. Je ne vois pas Gtk se mettre a dependre de Qt et je ne vois pas Trolltech adopter une technologie externe alors qu'elle a tant investi sur X et Qt.

A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.

Pour dbus, on note son arrivee dans Qt 4.2 :
http://doc.trolltech.com/4.2/qtdbus.html

Et pour ceux qui poseraient la question "quand est-ce que KDE va l'utiliser ?" ou "si Qt l'utilisait aussi, ce serait top", je vous informe que Qt possede un moteur de rendu qui fait exactement la meme chose que Cairo, mais qui s'appelle Arthur. Export SVG, rendu sur OpenGl, export PDF via backend d'impression, etc etc.

A noter que Riverbank computing, c'est une personne : Phil Thompson. C'est lui qui fait les binding de PyQt depuis Qt 1.4 et il assure par mal.