Salut tout le monde Le 13/05/05, Gontran<[EMAIL PROTECTED]> a écrit : > Je crois que ce que je vais dire ici ne va pas te plaire :-)
Pas de problème, si c'est constructif :-) > Pour moi, ton idée de mettre en place un frontal graphique est valable > uniquement parce que la syntaxe de Zenity est différente des autres *dialog. > Mais elle ne permettra pas pour autant d'aller au-delà du PPCD de toutes ces > alternatives. > > Par exemple, pour configurer la date du système, l'option --calendar de Dialog > est intéressante, mais elle n'est pas supportée par KDialog. Alors comment > faire ? C'est simple, l'option --calendar ne doit pas être gérée par ton > frontal graphique. Et il doit sûrement en être de même pour d'autres options. > Au final, on va se retrouver avec un petit groupe d'options réellement > communes à toutes les alternatives de dialog, et il va falloir se débrouiller > avec ça pour faire une interface qui tienne la route. De plus, à chaque fois > qu'on va gérer un nouvel outil de la famille *dialog, on risque de réduire le > peu d'options communes qu'il y avait. > > En outre, le PPCD ne s'applique pas uniquement à ce niveau. Le fait même > d'utiliser dialog est réducteur. Il exploite plutôt bien les possibilités du > mode texte, mais ses alternatives graphiques sont loin d'exploiter au maximum > toutes les possibilités du mode graphique. Les logiciels graphiques actuels > utilisent des widgets pour afficher des images, des arborescences > d'informations, des listes déroulantes avec des vignettes dans les > entrées ... aucune alternative graphique *dialog permet d'obtenir ce genre de > choses. Est-ce qu'il faut pour autant s'en passer ? Un simple bouton > comportant du texte accompagné d'une image est pourtant bien plus > « sympa » :-) . > > A vrai dire, je pense que même le dialog en mode texte est trop limité pour > nos besoins. Lorsque j'ai installé Nasgaia pour la première fois, j'ai trouvé > dommage qu'au moment de l'installation des paquets, il n'y ait qu'une seule > barre de progression qui indiquait l'avancement du paquet en cours > d'installation. J'aurais aimé qu'il y ait une deuxième barre de progression > qui indique l'état général d'avancement pour l'ensemble des paquets. Comment > faire ça avec dialog ? À ma connaissance, il ne peut gérer qu'une seule barre > de progression à la fois. > > En fait, ce n'est pas tant ton idée de frontal graphique que je remets en > cause, parce que je pense qu'il faudra utiliser quelque chose de ce genre. > Mais si on veut faire un Nsetup _convivial_ utilisable à la fois en mode > texte et en mode graphique, il faut utiliser autre chose que des *dialog. Je > pense qu'il vaut mieux utiliser de véritables toolkits graphiques. Et pour > ça, il faut utiliser autre chose que des scripts bash pour coder Nsetup. Il > faut utiliser un langage de programmation capable de s'interfacer avec une > librairie de widgets en mode texte et une autre en mode graphique. Je suis tout à fait de ton avis: plus je regarde les *dialog, plus je me rend compte des limites q'uils imposent par rapport aux possibilitées offertes par gtk2, qt... Mon idée de "frontaux" n'an effectivement que epu d'interet dans le contecte d'utilsation des *dialog, comme tu l'as si bien souligné. Et je dois reconnaitre que j'ai un effectivement peur que bash ne suffise plus pour Nsetup. Je prosose donc également de réfléchir à un autre langage pour Nsetup. Personnellement, je souhaiterait rester dans de l'interpreté, pour sa souplesse. Je ne vois pas l'utilité de sortir le C/C++ avec des dll etc... bref la grosse artillerie: la rapidité des langages interprétes est largement sufsante pour notre utilisation dans Nsetup Personellement, je me fait l'avocat de python: il est à mon avis la meileure solution à l'heure actuelle pour notre Nsetup: - il est pratique et répandu - il ressemble beaucoup au C avec lequel il supporte une collaboration poussée (modules écrits en C pour optimiser la vitesse, etc...) - il s'interface au moins avec ncurses (texte) et gtk2 (graphique). Cela ne m'étonnerait pas que ce soit également le cas pour qt, mais je n'ai pas encore regardé ça ;-) - il est surtout extremement modulaire; quoi de meiux pour notre architecture de Nsetup ? chaque module pourrait representer un module python :-D Donc perso je voterais pour Python > Voilà mon avis :-) Et revoici le mien :-D > ++ @+ guiguilinux
