Le Mercredi 18 Mai 2005 19:50, Julien L. a écrit : > >Quel serait le véritable intérêt d'utiliser Python dans ce cas ? Autant > >continuer ce que tu as fait en Bash :-) > >Perso, je reste convaincu que les Dialog en tout genre sont limités, et > >qu'on > >pourrait avoir beaucoup mieux, même en mode texte avec curses. > > Il y a toujours une limite. Tout toolkit a ses limites. Des fois, on > voudrait faire des trucs particuliers mais le toolkit ne le permet pas.
C'est vrai que chaque toolkit a ses limites. Mais pour moi, ils resteront toujours moins limité que les *dialog. :-) > C'est vrai qu'on peut sûrement faire des choses plus évoluées avec curses, > gtk, qt, ... mais à quel prix ? Pour écrire une boîte de dialogue avec un > menu fonctionnel, il faut au moins 20 lignes de code en python (à > multiplier par le nombre de toolkits que l'on veut supporter). > Pour écrire une boîte de dialogue avec un menu fonctionnel, il faut une > seule ligne de code en shell (bon, une grosse ligne mais une seule ligne C'est juste ça qui te fait peur ? ;-D Si ce n'est que ça, je suis prêt à écrire les quelques 19 lignes supplémentaires pour chaque toolkit si ça permet d'obtenir quelque chose de mieux :-) > Sur ce plan, le shell est plus simple pour développer et, pour moi, qui dit > simplicité de codage dit qualité de l'application. Ce n'est pas parce qu'il faut 20 lignes au lieu d'une que la qualité d'une application est différente. Pour moi, ça n'a rien à voir. La qualité d'une application se base sur d'autres critères. > > > > De meme, je n'ai effectivement trouvé aucune soultion curse utilsable > > > >par > >python > > > >http://www.amk.ca/python/howto/curses/ > > Le module curses est un module standard de la distribution python : > http://docs.python.org/lib/module-curses.html > > Il existe le module pygtk pour GTK2 et le module pyqt pour Qt mais ces > "wrappers" ne sont pas fournis en standard dans la distribution python. > Du côté des "wrappers" de toolkit, ce n'est pas un problème. Il y a ce > qu'il faut. Cependant, comme je le disais, il n'existe pas de module qui > abstrait tous les toolkits. Pourquoi cherches-tu absolument un module qui abstrait tous les toolkits ? Ça peut faciliter le développement, mais si ça n'existe pas, ce n'est pas plus gênant que ça pour autant. > Je ne suis pas d'accord avec ce que tu dis. Quelque soit le "design", quand > tu voudras ajouter un module, il faudra que tu rajoutes les boîtes de > dialogue, les zones de textes, les boutons correspondant à ce nouveau > module pour chaque toolkit. Je ne vois pas comment tu peux y couper. Mais je n'ai pas l'intention d'y couper :-) Ça va pas se faire tout seul non plus ! ;-) > De ce fait, je vois déjà ce qui va arriver : > - l'interface d'un module sera utilisable par un toolkit et par l'autre je ne vois pas pourquoi ? > - l'interface d'un module sera plus fonctionnel sur un toolkit que sur > l'autre toolkit (car des tests auront été effectués principalement sur un > seul toolkit) Là encore, je ne vois pas pourquoi. Soit on veut réellement plusieurs toolkits, et on s'en donne les moyens, soit on ne veut pas et on se limite à quelques-uns. Jusqu'à présent, on a dit qu'il y aurait une interface en mode texte et une autre en mode graphique. Si il y a des volontaires pour faire une interface en Qt, ok, mais qu'ils aillent jusqu'au bout. S'ils ne veulent pas, qu'ils ne commencent pas à en faire une. > A mon humble avis, en se limitant à dialog/gdialog/kdialog (qui, comme l'a > écrit Chicha, couvre la grande majorité des besoins), une interface écrite > avec un *dialog sera automatiquement valable avec un autre *dialog. Le code > n'est pas dupliqué. La création de l'interface n'est faite qu'une seule > fois dans le code. > > Je sais ce que vous allez me dire : les *dialog présentent des différences > dans les options qu'elles fournissent. Cependant, si une option est valable > sur dialog et pas sur kdialog, le développeur/testeur s'en rendra > rapidement compte et pourra corriger le tir. Non, je ne vais pas te dire ça :-) Je vais simplement dire que perso, j'aspire à un Nsetup qui ait de la « gueule », qui soit fonctionnel et agréable à utiliser. Et je ne vois pas pourquoi on se contenterait d'austères boites de dialogues qui n'exploitent pas tout le potentiel du mode graphique, quand on pourrait avoir une application qui en jette, même si elle est utilisée moins de 5 minutes par jour. Et même s'il faut écrire 10 fois plus de code pour ça, perso, je trouve que ça vaut le coup. Je ne pense pas que choisir telle solution parce qu'on a qu'une ligne de code à écrire au lieu de 20 soit vraiment ce qu'on appelle se donner les moyens de faire quelque chose de qualité. Une application digne de ce nom ne se code pas toute seule, et une distribution ne se fait pas toute seule non plus. Mais bon, peut-être que je vois trop grand et que je veux trop bien :-) ... > D'autre part, il me semble que vous oubliez de prendre en compte un point > important sur le choix du langage : l'exécution à partir du CD live. > > Avec python, il faudrait embarquer toute la distribution sur le CD (ainsi > que ses dépendances). Je ne sais pas combien fait une distribution python > installée sur disque. Je l'estime à quelques dizaines de Mo. Cela me paraît > chaud. > > Avec le shell, il suffit d'embarquer bash (obligatoire de toute façon) et > dialog. Tout cela a déjà été fait pour Nasgaia 1.0. Ça, c'est un argument de poids ! :-D Voilà un des points sur lequel les différents langages doivent être comparés. Bon, la version 1.0.1 occupe 441 Mo sur le CD, donc il reste de la place :-) Mais il vrai qu'un langage de programmation qui, avec les toolkits, occupe le moins de place possible permettra de laisser plus de place pour ajouter des paquets. ++ Gontran
