Le 17/05/05, Julien L.<[EMAIL PROTECTED]> a écrit : > Salut tout le monde, > Salut Guillaume, Salut Julien ;-)
> >Et si, je peut te citer au moins un cas ou un module fera appel à une > >multitude d'autres: > >le module "install", qui s'occuperat du processus d'installation, > >c'est à daire appeller les modules appropriés dans le bon ordre > > Euh... comprend pas là. :p L'idée est que l'installation soit effectuée par un module dédié, Qui s'occupe de la progression logique du processus en appellant les bons modules dans l'ordre (on eviter de se retrouver comme dans Nasgaia 1.0 face à un menu sans etre guidé --> perso j'avait assez apprécié, amis cela a déboussolé certains) > >Pour ce qui est de la fréquence d'utilisation, j'ai bon espoir d'y > >integrer un module servant de "front-end" à Ncooker: > >donc si, il sera utilisé tous les jours, au moins par les allergiques > >à la ligne de commande. > > Ce n'est pas ce que je voulais dire. Il sera peut être utilisé tous les > jours mais de façon occasionnelle. C'est le genre d'outil qu'on lance > pendant 5-10 minutes pour une tâche bien précise. Au contraire, un > navigateur est le genre d'application qu'on garde constamment sous le coude. > L'attente de l'utilisateur n'est pas la même entre ces deux types > d'application. Certes: je dois reconnaitre que je n'utilise pas tout le temps Synaptic sous mon Ubuntu: cependant j'appécie son confort et son efficacité > >De plus, l'utilsateur est exigeant: on ne peut se permettre de fournie > >un truc médiocre sous pretexte que cet outils n'est pas un navigateur: > >cela me désole, > >mais l'outil de configuration et celui d'installation comptent pour > >beaucoup dans l'image > >d'une distro... > > Ce n'est pas parce qu'on code en bash/dialog que l'application sera médiocre > ! Personnellement, je trouve que l'ancien Nsetup était très bien pour les > objectifs qu'il avait : installer la distribution et administrer le système. > Trouves-tu que le Nsetup de Martial était médiocre ? C'est pour moi une > référence en la matière. Il lui manquait juste des modules supplémentaires > et quelques ajustements. Le principe était bon. Loin, vraiment tres loin ( et ce n'est pas encore assez loin )de moi l'idée de considerer que le Nsetup de martial etait mediocre: je m'en suis largement inspiré et j'en ai repris de nombreuse idées. Le Nsetup de Nasgaia 1.0 reste à mon avis un modèle de simplicité et d'efficacité, meme si, comme tu le soulignes, il avait un certain nombre de manques > >De plus, l'un des objectifs de Nasgaïa est d'etre rapide et moderne: > >pour la rapidité, quand on connait la lourdeur de bash des qu'on > >aborde de gros projets, et qu'en plus on y rajoute des interfaces > >graphiques, j'ai peur que Nsetup tourne à la vitesse d'une > >trotinnette, sauf à avoir un ordinateur musclé... > > Encore une fois, trouves-tu que le Nsetup de Martial était lent ? Bien sûr, > il y avait l'étape de listage des paquets qui prenait un certain temps mais > on sait qu'il existe des solutions pour contourner ce problème (notamment, > l'idée que la liste soit fixée et non générée automatiquement). Non, le Nsetup de Martial n'etait pas lent ( pas au point de choquer en tout cas par rapport à d'autres outils du meme genre ) Certes, il y a des moyens, comme tu le souligne, de contourner ce probleme: ce n'est pas là le principal motif de ma proposition > >Enfin, concernant la modernité, bash/dialog, on est revenu au temps > >des premiers Unix ou presque... Python, quant à lui, est un langage > >moderne, rapide, portable et optimisé, orienté objet et modulaire > >supportant à peu près tout ce qui ce fait comme toolkit graphique... > > Est-ce que le critère de modernité est vraiment judicieux dans le choix d'un > outil ? Est-ce que c'est parce que python est un langage qui est né après le > langage shell que c'est un meilleur langage ? Voyons, ce n'est pas sérieux, > surtout que le bash est toujours en développement. Oui, mais de par sa nature meme bash ne peut s'affranchir de certaines limites, comme tout language d'ailleurs: il s'agit d'un language conçut pour etre utilisé à la volée dans sa console par l'utilisateur ou pour ecrire des petits scripts: en aucun cas il n'est souhaitable de l'utiliser pour un gros projet, car il n'est pas vraiment prévu pour ça: Hotplug, par exemple, etait auparavant ecrit en bash. Au vu de sa lourdeur, il a été entierement réécrit en C peu apres la sortie deu noyau 2.6: Après, je suis d'accord qu'il faut nuancer la définitoion de "gros projet", pour voir si on y classe ou non Nsetup: mais a mon avis, ce doit etre le cas :-) > Je connais personnellement bien Python pour y avoir passé de nombreuses > heures. Je ne pense pas que cela soit le langage le plus adapté pour ce > qu'on veut faire. Comme je l'ai déjà écrit, l'appel d'une commande système > sera plus délicat qu'avec le shell. De plus, même si il est vrai qu'il > existe de nombreux modules permettant d'utiliser les toolkits graphiques, il > n'existe aucun module qui unifie les toolkits curses et GTK2. Il y a le > module wxPython mais il ne fait pas curses. Il existe aussi le projet anygui > (http://anygui.sourceforge.net) mais il semble abandonné. > > Deux solutions vont s'ouvrir à toi : > - soit tu fais une interface Nsetup pour chaque toolkit. Pour moi, c'est le > risque d'avoir des fonctionnalités présentes sur une interface et pas sur > une autre... > - soit tu fais un backend qui unifie les toolkits. Pour moi, cela me semble > hors du cadre du projet et aussi assez difficile à réaliser (il suffit de > voir le projet anygui qui a abandonné). Là, je reconnait que tu mets le doigt sur la faille qui m'est moi aussi apparue en examinant les librairies graphiques disponibles sous python de plus près: Il n'y a effectivment a ma connaisance aucune lib qui serait une sorte d'equivalent à dialog en bash pour faire abstraction du toolkit utilisé. De meme, je n'ai effectivement trouvé aucune soultion curse utilsable par python Cet effectivement cette enorme probleme, et les consequences qu'il implique et que tu décrits, qui là me font douter: c'est surotu sur ce point que je suis d'accord avec toi pour dire que python n'est pas forcément un bonne idée. Pour l'instant, j'essaie de trouver à un solution, mais je dois reconanitre que si je n'en trouve pas, cela nous amenrat sans doute à retombre dna sl'utilisation de bash. Mais je continue à chercher pour eviter cela si c'est possible: passer en python continuerait à présenter un nombre énorme d'avantage si ce problème est résolu > >Perso, je reste pour Python; j'ai déjà pu essayer l'intercation avec > >des comamndes comme ls, et cela marche tout aussi bien et meme mieux > >qu'en bash, car le code est beaucoup plus clair moderne et lisible ( > >vive les indentations python :-D ). > > Ce n'est pas parce que le code est plus clair que cela s'exécute mieux. Dans > tous langages, c'est au développeur de garder un code clair et lisible. > Sinon, je ne vois pas ce que tu entends quand tu dis que le code Python est > moderne. Chaque langage a sa syntaxe et rien de plus. Certes, mais reconnait que certains langages te facilitent plus la tache que d'autre ;-) ( Non, je ne parlerai pas de Perl comme contre exemple... ah flute ça y est j'en ai parlé ;-) ). Concernant la "modernité" de python, elle vient a mona vis du fait que ce langage est: - orienté objet - gere les exceptions - supporte de maniere native la modularité - est "livré" avec une serie de librairies completes comprenant tout le contenu usuelle aisement reutilsable: pas besoin de reinventer la roue - est optimisé et portable: utilisation de bytecode universel pour augmenter la vitesse d'execution, machine virtuelle disponible sur toutes les plate-formes, etc... Je suis d'accord que chacun a sa definiton de "modernité" en langages, mais cela rentre dans la mienne :-D > Hier, je relisais les messages postés le mois dernier sur la liste de > diffusion. J'ai l'impression qu'on revient toujours au même débat à propos > de Nsetup. Il me semble qu'on s'était plus ou moins mis d'accord sur ce > sujet. Je t'invite vraiment à relire le fil de discussion intitulé > "Interface graphique de Nsetup". Je l'ai déjà lu en long, en large et en travers et je le garde à l'esprit, rassure-toi :-D Après, pour ce qui est de revenir au meme debat, oui et non, c'est assez vrai: a l'époque nous avions ecarté d'office l'utilisation de tout autre langage de manière inflexible et arretée: je pense donc que niveau "ouverture", il y a aun progres :-) @+ Julien, @+ à tous les GDN ( et aux autres ;-) ) guiguilinux
