> Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
Parfois tu as des compilateurs vraiment pourri. Prenons au hasard Visual C++ (le meme qui est super rapide):
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.
Mais oui. Et chaque changement de compilateur est un nouvel exploit pour chaque distrib, surtout quand ces messieurs de gcc s'amusent (si on peut dire) a retirer des trucs qui marchaient avant.
Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4 . Voila comment l'exploit se realise. Mais c'est pour la bonne cause, c'est pour le standard.
Je ne suis pas alle voir mais je suis sur que sur kde-core-devel, ils discutent deja des nouvelles perfs et du code qu'il faut corriger pour passer sur gcc 3.4 . Ce temps aurait pu etre investi a corriger des bugs mais rien n'est plus important que de respecter le standard du C++.
J'espere pour Soustroup qu'il verra avant sa mort un compilateur qui respecte le standard qu'il a ecrit. Sinon, ca serait triste pour lui quand meme.
Tout ca est vrai. Notamment avec boost, visual souffre pas mal.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.
Le probleme des standards ne se limite pas a l'axiome "tu dois respecter les standards". Je bosse par exemple dans un milieu (la carte a puce sans-contact) ou les mecs qui ecrivent les standards sont malheureusement un peu trop chercheurs. Ils ont plein de bonnes idees qui sont irrealisables techniquement, mais qui passent dans les standards. Resultat, le standard est impossible a implementer avec la techno d'aujourd'hui.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).
> Mouais... Comparé au temps d'accés à ton fichier de conf, le parsing xml
> est probablement pas très couteux.
Chaque microseconde compte parce que beaucoup de fichiers sont lu avant qu'une application puisse se lancer. Typiquement, tu lances KDE:
- dcop lit son fichier de conf
- sycoca lit son fichier de conf
- kwin lit son fichier de conf
Ensuite, tu lances konqueror:
- il lit tout son fichier de conf et l'interpret
- il charge khtml qui va faire de meme
En faisant des optimisations simples sur les fichiers de conf (le charger tout d'un coup, ne faire la conversion unicode qu'au dernier moment, n'interpreter que la cle qu'on recherche, ...), KDE avait divise par 5 le temps subjectif de chargement d'une application (temps subjectif au sens ou c'est le temps ou l'utilisateur a l'impression qu'il se passe qqch). Pourtant, c'etait avec un format hyper-simple style .ini
Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
Il pense probablement a la DLL de windows gerant les styles sous windows XP. La dependance est configurable donc ca n'est pas un obstacle pour livrer Qt4 sous windows.
kconfig permet en effet de verouiller des cles pour non-modification.
Il fait la fusion entre un fichier de conf global et un fichier de conf local
Lors d'une modif, il ne va enregistrer la modif que si elle differe de la config par defaut.
Il s'appuie sur le filesystem pour stocker les fichiers de config. Le demon ksycoca utilise libfam (file access monitoring) pour noter les changements et les notifie via dcop.
Comme il s'appuie sur le systeme de fichier, c'est relativement simple de centraliser une config sur un serveur: tu montes un repertoire KDE par nfs.
Apres, pour les autres possibilites de gconf, je pense pas que kconfig fasse. Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.
faut voir que la versoin KDE n'est qu'un frontend. Le langage de script est integre au backend (libyzis) qui lui ne depend pas de KDE. On verra au moment ou on fait ca mais il est hors de question que libyzis depende de KDE. Si on peut extraire kjsembed, ca peut valoir le coup.
L'avantage de lui, c'est qu'il est vraiment developpe pour etre embarque facilement. Je sais pas si c'est le cas de kjsembed.
quand tu dis une ou deux touches, tu comptes les alt/meta/esc/ctrl/shift ? Parce que c'est justement le genre de touche difficile d'acces sur un clavier, qui vont augmenter les symptomes: tu es oblige de te tordre legerement la main pour y acceder.
Si on y reflechit, les touches de controle devraient etre au milieu du clavier.
Aller, quelques exemples:
- avancer d'un mot: vi=w, emacs=C-F soit 1 vs 2
- sauver le buffer courant: vi=:w, emacs=C-X C-S soit 2 vs 4
- debut de phrase: vi=0, emacs=C-A soit 1 vs 2
- quitter sans sauver: vi=:q!, emacs=C-X C-C n soit 3 vs 5
etc etc
La ou emacs assure, c'est sur la richesse des fontionnalites. Le chercher/remplacer gere aussi mieux les majuscules et le yanking ring est vraiment un paradis (M-Y pour ceux qui voient pas ce que c'est).
Euh, l'editeur parfait suscite, est-ce que les developpeurs ont enfin realise que vouloir modifier une option de config et coder en lisp sont deux choses differentes et que la premiere ne devrait pas implique la seconde ?
Sinon, pour faire dans le troll vi/emacs, un des trucs que j'apprecie dans vi, c'est que beaucoup de fonctions sont accessibles avec simplement une touche du clavier. C'est difficile de s'y faire quand on debute, mais un des avantages, c'est qu'on bouge tres peu les doigts pour executer une action. Sous un editeur classique (et emacs ne fait pas exception), les actions complexes doivent etre activees par une combinaison de touches. Donc d'une part ca prend plus de temps, d'autre part (j'eviterai le troll Esc-Meta-Alt-Ctrl-Shift), cela fatigue plus les doigts. Ce dernier point est significatif pour des gens tapant beaucoup au clavier et souffrant de RSI (repetitive strain injury, blessure liee a des gestes reptitifs) ou de carpal tunnel (traduction wanted).
Reflechissez-y les jeunes quand se posera la question la plus importante de votre vie: "est-ce que j'apprend vi ou emacs ?"
Oui. On utilise quand meme KDE pour la partie graphique, ncurses pour le texte donc ca nous epargne pas mal de probleme.
Comme on le disait dans l'annonce, le syntax highlighting est pique a kate.
Pour ce qui est de l'immonde langage de script de vim, on remplacera ca avantageusement par un truc moderne, genre lua (www.lua.org)
Pour la gestion des regexp, de l'unicode et des polices, on s'en remet a Qt. Pour la communication multi-fenetre, peut-etre qu'on utilisera un bout de dcop ou de dbus.
Donc le moteur lui-meme est re-ecrit a la mano mais tout ce qui est autour utilise les technos existantes.
Pour la gestion des options, je vois gros comme une patate qu'on va utiliser le dernier generateur automatique de dialogue de configuration de KDE (ou bien on se recoder a un truc a la main).
Faut voir que dans vim, il y a du code bas-niveau X pour gerer la communication vim-server / vim-client, il y a vim_strcmp et vim_strdup. On peut pas maximiser correctement une fenetre parce que vim pense etre plus fort que le window manager (plus precisement, il marche dans des environnements sans window manager), etc etc.
On peut voir vim un peu comme OpenOffice. Il y a tout dedans donc c'est hyper portable. Mais niveau code, il y a prix qui est tres cher a payer.
Trolltech donne plusieurs raisons pour lesquelles distribuer Qt sous GPL pour windows leur poserait des problemes.
Le moins que tu puisses faires si tu pretends leur apprendre a faire leur business, c'est au moins de t'interesser a leur problematique. Ton post actuel ne merite qu'un moinssage, vu qu'il n'apporte rien au debat a part le fait que tu rales.
> Là ou c'est pernicieux , c'est que la communté libre leur a permis de
> se développer grâce notamment au support de KDE
Ah ouai ? Je suis un fan de KDE mais faudrait pas croire que c'est le centre du monde. C'est pas KDE qui a permis a Trolltech d'etre populaire sur windows et sur MacOS, ou de faire une version embarquee. C'est pas les devs de KDE qui fournissent les tonnes de doc et de code de Qt.
Il y a des interactions mais Trolltech a une existence en dehors de KDE.
Quant a la version non-commercial, c'est carrement l'inverse. Ca a fait perdre de l'argent a Trolltech et donc ca ne les a pas aide a se developpe (d'ou le fait qu'ils n'ont pas renouvele l'experience).
Pour que KDE accepte de se passer de DCOP, il faudra que DBUS propose des avantages nets, ce qui n'est pas encore le cas. DBUS pour l'instant n'est meme pas adopte pas Gnome, et ne permet pas de faire tout ce que fait dcop.
J'espere aussi que la transition se fera mais faut pas croire que ca sera rapide. Peut-etre pour KDE4. Il n'a pas fallu beaucoup de temps pour faire DCOP, mais certaines finitions prennent du temps et de l'experience d'utilisation. Il faut laisser DBUS maturer encore.
Il existe un petit projet permettant a gtk d'utiliser le theme Qt courant. Sinon, la problematique de la couleur de fond a normalement ete resolu depuis longtemp. Maintenant, la couleur de fond est mise a jour pour gtk quand tu changes de theme/style sous KDE. Je suis surpris que ca ne soit pas le cas chez toi.
Pourquoi ce serait pas Gnome qui utiliserait kconfig ? kconfig lui-meme n'a aucune dependance avec KDE et il est facile a une appli exterieure de relire les fichires de conf KDE qui sont bien organises.
Pour resume, c'est difficile d'avancer parce que les deux solutions sont toutes les deux techniquement valables et en changer aurait d'une part des gros impacts en architectures, d'autre part un gros impact sur le bureau qui changerait.
La semaine derniere, un mec a propose sur la liste freedesktop un autre systeme de configuration global. Ce qui est ressorti de la facon dont il s'est fait allume, c'est que kconfig et gconf sont tous les deux des solutions bien eprouvees techniquement, qu'on ne peut pas remplacer facilement.
Les developpeurs ont bien la volonte de faire un systeme de configuration commun, pour partager des choses comme la bases de donnees mime, des themes, la configuration d'applications communes mais la solution technique n'a pas encore ete trouvee.
En general, Trolltech n'aime pas faire du vaporware et est assez protecteur de ses sources tant qu'elle n'ont pas atteint un etat stable. A vue de nez, je dirai qu'on devrait voir des snapshots arriver a partir de cet ete.
> des millions de soft mineurs en shareware que personne n'utilise.
Je crois que tu t'illusionnes gravement sur le succes du libre sous windows. Il y a bien plus de gens qui utilisent winzip ou irfan view que tous les utilisateurs de Mozilla, OpenOffice et psi cumules.
> Je peux comprendre leur peur de non-respect de la GPL mais c'est gênant.
La dessus, on est tous d'accord, Mathias y compris. Mais il y a un moment ou tu dois gagner ta croute avec le logiciel que tu vends et ils n'ont pas le choix. Trolltech n'est pas ferme, l'histoire le montre et l'ouverture recente de Qt sous Apple le rappelle. Mais sous windows, c'est la qu'ils gagnent une part importante de leurs revenus, qu'ils perdraient sinon.
Je pense que le monde du libre a plus a gagner avec Trolltech beneficiaire et continuant a developper Qt, que avec Trolltech en faillite et Qt en GPL sous windows.
Pour reprendre tes reponses:
- sisi, ca sert. La preuve en a ete donne par le passe.
- oui, mais ce serait deja un gros progres. Mathias avait l'air ouvert a l'idee d'avoir un moyen pour les projets open source de beneficier de Qt pour windows.
- oui et non. Il y a deux projets, un projet par cygwin/x11 et un projet pour porter Qt en natif.
> C'est un risque minime ca permet de faire connaitre la GPL.
Non, c'est un risque majeur pour Qt et ils font deja connaitre la GPL a des gens que ca interesse, a savoir la communaute Linux et la communaute Mac.
Quand ils ont sorti Qt non commercial, leurs ventes ont baisse dramatiqueemnt. Pourtant, je n'ai pas entendu parle de projet libre ou de freeware ayant achete Qt. Donc la baisse des ventes est bien liee a des boites qui n'ont pas achete Qt quand elles auraient du le faire.
> 1. Utilisation illicite volontaire (vente de produit commerciaux lié avec Qt
> version GPL), c'est possible mais si le produit marche ils payeront
> rapidement la license Qt pour ne pas rester dans l'illegalité.
C'est pas a Trolltech de financer le developpement de societe de logiciel. Surtout que pour une boite, c'est pas tres cher. En plus, beaucoup de ces societes servent des marches ultra-specialise dont personne n'entendra jamais parle. Trolltech ne recuperera pas le manque a gagner dans cette situation.
> 2. Utilisation illicite involontaire, c'est pas bien grave.
> firefox, thunderbird, gaim (ainsi que abiword et gnumeric dans un futur proche j'espère)
Tout ce ne fait pas une communaute suffisante pour interesser Trolltech. Ccompare au nombre de logiciels KDE, Qt, Gtk ou au nombre de logiciels disponibles sous Windows en shareware.
Pour que ca soit vraiment interessant pour Trolltech, il faut une communaute de developpeur pret a utiliser Qt, comme on en voit sous KDE.
Face a ce probleme de Qt/Windows, il y a trois solutions:
- continuer a faire chier Trolltech pour qu'ils releasent Qt sous GPL sous windows.
- demander comme l'a fait psi une licence speciale juste pour leur projet Open Source
- aider le portage en natif windows de Qt (kde-cygwin.sf.net)
- utiliser PyQt qui est abordable en prix (mais toujours pas gratuit)
- acheter le dernier bouquin sur Qt et obtenir Qt 3 non commercial pour windows.
- qui a dit que je savais compter ?
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.
[^] # Re: Sortie de GCC 3.4.0
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4 . Voila comment l'exploit se realise. Mais c'est pour la bonne cause, c'est pour le standard.
Je ne suis pas alle voir mais je suis sur que sur kde-core-devel, ils discutent deja des nouvelles perfs et du code qu'il faut corriger pour passer sur gcc 3.4 . Ce temps aurait pu etre investi a corriger des bugs mais rien n'est plus important que de respecter le standard du C++.
J'espere pour Soustroup qu'il verra avant sa mort un compilateur qui respecte le standard qu'il a ecrit. Sinon, ca serait triste pour lui quand meme.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
ddd a des trucs un peu chiant (l'idee de sauver toutes les sessions avec un no a 25 chiffres) mais est quand meme bien pratique.
Sinon, quelqu'un sait ou trouver le plugin python pour ddd ? J'ai trouve des liens qui en parlent sur internet mais impossible de trouver ou il est.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
> est probablement pas très couteux.
Chaque microseconde compte parce que beaucoup de fichiers sont lu avant qu'une application puisse se lancer. Typiquement, tu lances KDE:
- dcop lit son fichier de conf
- sycoca lit son fichier de conf
- kwin lit son fichier de conf
Ensuite, tu lances konqueror:
- il lit tout son fichier de conf et l'interpret
- il charge khtml qui va faire de meme
En faisant des optimisations simples sur les fichiers de conf (le charger tout d'un coup, ne faire la conversion unicode qu'au dernier moment, n'interpreter que la cle qu'on recherche, ...), KDE avait divise par 5 le temps subjectif de chargement d'une application (temps subjectif au sens ou c'est le temps ou l'utilisateur a l'impression qu'il se passe qqch). Pourtant, c'etait avec un format hyper-simple style .ini
Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 6.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
Il fait la fusion entre un fichier de conf global et un fichier de conf local
Lors d'une modif, il ne va enregistrer la modif que si elle differe de la config par defaut.
Il s'appuie sur le filesystem pour stocker les fichiers de config. Le demon ksycoca utilise libfam (file access monitoring) pour noter les changements et les notifie via dcop.
Comme il s'appuie sur le systeme de fichier, c'est relativement simple de centraliser une config sur un serveur: tu montes un repertoire KDE par nfs.
Apres, pour les autres possibilites de gconf, je pense pas que kconfig fasse. Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
L'avantage de lui, c'est qu'il est vraiment developpe pour etre embarque facilement. Je sais pas si c'est le cas de kjsembed.
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 1.
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
Si on y reflechit, les touches de controle devraient etre au milieu du clavier.
Aller, quelques exemples:
- avancer d'un mot: vi=w, emacs=C-F soit 1 vs 2
- sauver le buffer courant: vi=:w, emacs=C-X C-S soit 2 vs 4
- debut de phrase: vi=0, emacs=C-A soit 1 vs 2
- quitter sans sauver: vi=:q!, emacs=C-X C-C n soit 3 vs 5
etc etc
La ou emacs assure, c'est sur la richesse des fontionnalites. Le chercher/remplacer gere aussi mieux les majuscules et le yanking ring est vraiment un paradis (M-Y pour ceux qui voient pas ce que c'est).
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
Sinon, pour faire dans le troll vi/emacs, un des trucs que j'apprecie dans vi, c'est que beaucoup de fonctions sont accessibles avec simplement une touche du clavier. C'est difficile de s'y faire quand on debute, mais un des avantages, c'est qu'on bouge tres peu les doigts pour executer une action. Sous un editeur classique (et emacs ne fait pas exception), les actions complexes doivent etre activees par une combinaison de touches. Donc d'une part ca prend plus de temps, d'autre part (j'eviterai le troll Esc-Meta-Alt-Ctrl-Shift), cela fatigue plus les doigts. Ce dernier point est significatif pour des gens tapant beaucoup au clavier et souffrant de RSI (repetitive strain injury, blessure liee a des gestes reptitifs) ou de carpal tunnel (traduction wanted).
Reflechissez-y les jeunes quand se posera la question la plus importante de votre vie: "est-ce que j'apprend vi ou emacs ?"
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 3.
Comme on le disait dans l'annonce, le syntax highlighting est pique a kate.
Pour ce qui est de l'immonde langage de script de vim, on remplacera ca avantageusement par un truc moderne, genre lua (www.lua.org)
Pour la gestion des regexp, de l'unicode et des polices, on s'en remet a Qt. Pour la communication multi-fenetre, peut-etre qu'on utilisera un bout de dcop ou de dbus.
Donc le moteur lui-meme est re-ecrit a la mano mais tout ce qui est autour utilise les technos existantes.
Pour la gestion des options, je vois gros comme une patate qu'on va utiliser le dernier generateur automatique de dialogue de configuration de KDE (ou bien on se recoder a un truc a la main).
Faut voir que dans vim, il y a du code bas-niveau X pour gerer la communication vim-server / vim-client, il y a vim_strcmp et vim_strdup. On peut pas maximiser correctement une fenetre parce que vim pense etre plus fort que le window manager (plus precisement, il marche dans des environnements sans window manager), etc etc.
On peut voir vim un peu comme OpenOffice. Il y a tout dedans donc c'est hyper portable. Mais niveau code, il y a prix qui est tres cher a payer.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
http://svn.freenux.org/xml/yzis/trunk/README(...)
Voir aussi notre discussion sur vim-dev il y a deux ans pour essayer de corriger le probleme.
http://marc.theaimsgroup.com/?l=vim-dev&m=103648575424303&w(...)
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Trolltech donne plusieurs raisons pour lesquelles distribuer Qt sous GPL pour windows leur poserait des problemes.
Le moins que tu puisses faires si tu pretends leur apprendre a faire leur business, c'est au moins de t'interesser a leur problematique. Ton post actuel ne merite qu'un moinssage, vu qu'il n'apporte rien au debat a part le fait que tu rales.
> Comment je fais pour downloader Qt 3.3 pour Windows pour mon projet GPL
http://kde-cygwin.sf.net(...)
> Là ou c'est pernicieux , c'est que la communté libre leur a permis de
> se développer grâce notamment au support de KDE
Ah ouai ? Je suis un fan de KDE mais faudrait pas croire que c'est le centre du monde. C'est pas KDE qui a permis a Trolltech d'etre populaire sur windows et sur MacOS, ou de faire une version embarquee. C'est pas les devs de KDE qui fournissent les tonnes de doc et de code de Qt.
Il y a des interactions mais Trolltech a une existence en dehors de KDE.
Quant a la version non-commercial, c'est carrement l'inverse. Ca a fait perdre de l'argent a Trolltech et donc ca ne les a pas aide a se developpe (d'ou le fait qu'ils n'ont pas renouvele l'experience).
Tu dis vraiment n'importe quoi.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 3.
J'espere aussi que la transition se fera mais faut pas croire que ca sera rapide. Peut-etre pour KDE4. Il n'a pas fallu beaucoup de temps pour faire DCOP, mais certaines finitions prennent du temps et de l'experience d'utilisation. Il faut laisser DBUS maturer encore.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 4.
Pour resume, c'est difficile d'avancer parce que les deux solutions sont toutes les deux techniquement valables et en changer aurait d'une part des gros impacts en architectures, d'autre part un gros impact sur le bureau qui changerait.
La semaine derniere, un mec a propose sur la liste freedesktop un autre systeme de configuration global. Ce qui est ressorti de la facon dont il s'est fait allume, c'est que kconfig et gconf sont tous les deux des solutions bien eprouvees techniquement, qu'on ne peut pas remplacer facilement.
Les developpeurs ont bien la volonte de faire un systeme de configuration commun, pour partager des choses comme la bases de donnees mime, des themes, la configuration d'applications communes mais la solution technique n'a pas encore ete trouvee.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 5.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 3.
Je crois que tu t'illusionnes gravement sur le succes du libre sous windows. Il y a bien plus de gens qui utilisent winzip ou irfan view que tous les utilisateurs de Mozilla, OpenOffice et psi cumules.
> Je peux comprendre leur peur de non-respect de la GPL mais c'est gênant.
La dessus, on est tous d'accord, Mathias y compris. Mais il y a un moment ou tu dois gagner ta croute avec le logiciel que tu vends et ils n'ont pas le choix. Trolltech n'est pas ferme, l'histoire le montre et l'ouverture recente de Qt sous Apple le rappelle. Mais sous windows, c'est la qu'ils gagnent une part importante de leurs revenus, qu'ils perdraient sinon.
Je pense que le monde du libre a plus a gagner avec Trolltech beneficiaire et continuant a developper Qt, que avec Trolltech en faillite et Qt en GPL sous windows.
Pour reprendre tes reponses:
- sisi, ca sert. La preuve en a ete donne par le passe.
- oui, mais ce serait deja un gros progres. Mathias avait l'air ouvert a l'idee d'avoir un moyen pour les projets open source de beneficier de Qt pour windows.
- oui et non. Il y a deux projets, un projet par cygwin/x11 et un projet pour porter Qt en natif.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 2.
Non, c'est un risque majeur pour Qt et ils font deja connaitre la GPL a des gens que ca interesse, a savoir la communaute Linux et la communaute Mac.
Quand ils ont sorti Qt non commercial, leurs ventes ont baisse dramatiqueemnt. Pourtant, je n'ai pas entendu parle de projet libre ou de freeware ayant achete Qt. Donc la baisse des ventes est bien liee a des boites qui n'ont pas achete Qt quand elles auraient du le faire.
> 1. Utilisation illicite volontaire (vente de produit commerciaux lié avec Qt
> version GPL), c'est possible mais si le produit marche ils payeront
> rapidement la license Qt pour ne pas rester dans l'illegalité.
C'est pas a Trolltech de financer le developpement de societe de logiciel. Surtout que pour une boite, c'est pas tres cher. En plus, beaucoup de ces societes servent des marches ultra-specialise dont personne n'entendra jamais parle. Trolltech ne recuperera pas le manque a gagner dans cette situation.
> 2. Utilisation illicite involontaire, c'est pas bien grave.
Ben si, c'est grave!
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Tout ce ne fait pas une communaute suffisante pour interesser Trolltech. Ccompare au nombre de logiciels KDE, Qt, Gtk ou au nombre de logiciels disponibles sous Windows en shareware.
Pour que ca soit vraiment interessant pour Trolltech, il faut une communaute de developpeur pret a utiliser Qt, comme on en voit sous KDE.
Face a ce probleme de Qt/Windows, il y a trois solutions:
- continuer a faire chier Trolltech pour qu'ils releasent Qt sous GPL sous windows.
- demander comme l'a fait psi une licence speciale juste pour leur projet Open Source
- aider le portage en natif windows de Qt (kde-cygwin.sf.net)
- utiliser PyQt qui est abordable en prix (mais toujours pas gratuit)
- acheter le dernier bouquin sur Qt et obtenir Qt 3 non commercial pour windows.
- qui a dit que je savais compter ?