Quelques compléments d'informations et réactions à ce qu'à dit guguilinux :-)
> NOUVELLE GESTION DES MODULES Le but de ces fonctions est encore une fois de faciliter la vie des développeurs de modules. Pour info, la différence entre une commande et un module (en ce qui concerne Ncooker) est qu'une commande est destinée à pouvoir être lancée soit en ligne de commande ($ Ncooker <command> ...), soit par une autre commande/module. Alors qu'un module est uniquement destiné à être utilisé par une autre commande/module. La distinction entre les deux ne se fait pas au niveau du code (le script d'une commande est structuré de la même manière que celui d'un module), mais au niveau de l'organisation sur le disque : les commandes sont dans un répertoire différent de celui des modules. Ainsi run_command cherche la commande à lancer dans le premier répertoire, et run_module dans le second. L'objectif est qu'un développeur qui a besoin de lancer une commande (ou un module) depuis son propre module n'ait pas à se soucier de l'endroit où elle se trouve sur le disque. Il utilise simplement « run_command <nom de la commande> <paramètres> » et Ncooker se débrouille pour la trouver et la lancer. Pour modulariser les choses, chaque développeur peut développer un module et des sous-modules qui lui sont propres. Là encore, l'idée est que le développeur n'est pas à se soucier de l'endroit où se trouvent les sous-modules sur le disque, il utilise « run_submodule <nom du sous module> <paramètres> » et Ncooker se débrouille à nouveau pour le trouver et le lancer. Mais il va le rechercher uniquement dans les sous-modules propres au module en cours d'exécution. Après d'autres fonctions pourraient être utiles, comme : sListCommands() : retourne la liste des commandes disponibles sListModules() : retourne la liste des modules disponibles bIsCommandAvailable() : indique si la commande demandée est disponible bIsModuleAvailable() : indique si le module demandé est disponible bIsSubModuleAvailable() : indique si le sous-module demandé est disponible Ces fonctions permettraient à une commande/module de réaliser de manière optionnelle certaines opérations en fonction de la présence ou non de certaines commandes/modules/sous-modules qui pourraient être installées en extra. De même pour les sous-modules, ces fonctions sListSiblingModules() : liste les modules « frères » du module appelant bIsSiblingModuleAvailable() : indique si le module « frère » demandé est disponible pourraient être utiles. Je pense notamment au sous-module Mirror du module Download. Les sous-modules Mirror, http et ftp sont installés dans le même répertoire, et Mirror utilise ses modules frères pour télécharger les fichiers en fonction de l'URL des miroirs. Il pourrait utiliser bIsSiblingModuleAvailable() pour savoir s'il existe un module frère permettant de prendre le type d'URL trouvé dans la liste des mirroirs. > VOCATION DE NSETUP: Tout est dit :-) Je pense effectivement qu'il vaut mieux envisager Nsetup comme une interface utilisateur placé au-dessus d'une multitude d'outils en ligne de commande déjà existants. Et de développer uniquement les outils en ligne de commande manquants. > INTERFACES GRAPHIQUES Je crois que ce que je vais dire ici ne va pas te plaire :-) 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. Voilà mon avis :-) ++ Gontran
