Le 15/05/05, Julien L.<[EMAIL PROTECTED]> a écrit :
> Bonjour tout le monde,
>
>
> >NOUVELLE GESTION DES MODULES
> >
> >Avant tout, nous avons mis au point une nouvelle gestion des modules:
> >cette nouvelle gestion est conçue pour concilier puissance et
> >facilité, et sera utilisée de manière universelle par Nsetup ainsi que
> >tous ses modules pour retrouver leurs petits. En voici les grandes
> >ligne:
> >
> >A tout moment un module peut faire appel à trois fonction s'il
> >souhaite executer un autre composant de Nsetup:
> >
> >- run_module() : cette fonction permet module de Nsetup en lui passant
> >les arguments, son chemin en partant de modules/ comme racine
> >
> >- run_command() : fonction completement analogue à modules, si ce
> >n'est que certaines variables changent, en particulier la racine qui
> >est alors "commands/"
> >
> >- run_submodule() : nous arrivons ici à la réelle innovation: cette
> >fonction a pour seul et unique but de lancer un sous-composant du
> >module courant, contrairement aux deux précedentes qui ont pour portée
> >la totailté de l'arborescence concernée.
> >
> >Le but est de ce découpage est de faciliter la gestion des
> >modulescette dernière fonction permet d'eviter une syntaxe longue pou
> >invoquer un simple sous module.
> >
> >NB: Dans la pratique cette run_submodule() gère aussi les
> >"sous-commandes". Elle utilise donc la notion de "module" au sens
> >large et permet à notre script d'acceder à ses sous-scripts: ne vous
> >arrêtez donc pas sur son nom :-D
> >
> >Ces fonctions sont conçues pouer etre utilsées de manière universelle:
> >
> >Contrairement au Ncooker actuel,
> >où chaque module se "débrouille" avec ses sous modules,
> >elles constitueront une API accessible à tous les composants de Nsetup
> >pour gerer les communications entre modules :-D
>
> Y aura-t-il vraiment "communication" entre les modules de Nsetup ? Je ne
> vois pas d'exemple de module qui pourrait appeler d'autres modules. Selon
> moi, les modules de Nsetup sont indépendants les uns des autres. Par contre,
> il me paraît logique qu'un module puisse appeler un de ses sous-modules.
> Maintenant, si ces trois fonctions sont présentes dans un but d'homogénéité
> entre Ncooker et Nsetup, cela ne me dérange pas.
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
> Ce qui me paraît important, c'est de définir l'API d'un module Nsetup,
> c'est-à-dire, l'ensemble des fonctions à coder qui font d'un simple script,
> un module Nsetup.
Tout à fait d'accord avec toi :-)
> >VOCATION DE NSETUP:
> >
> >Nsetup a avant tout pour but de fournir une interface de configuration
> >à l'utilsateur: Dans cette optique, il ne fera QUE CELA.
> >
> >Il n'integrera aucun outil en propre, et fera systematiquement appel
> >aux autres commandes dédiées comme lilo, grub, etc... pour configurer
> >l'ordinateur.
>
> Jusque là, je suis d'accord.
>
>
> >Nous développerons effectivement notre propre solution
> >si un outil n'existe pas encore, mais sous la forme d'un outil
> >indépendant de Nsetup:
> >
> >Ainsi la commande NetNsetup de Azmodai, sera accessible comme tout
> >autre commande du système: Nsetup se contenera d'en fournir une
> >interface, et son utilsation ne sera restreinte ni à lui, ni même à
> >Nasgaïa
>
> Humm... Dans le cas de la configuration réseau, il existe déjà plein
> d'outils (ifconfig, ppp, ...). Développer une commande NetSetup rentre en
> contradiction avec ce que tu as écrit plutôt. Personnellement, je voyais
> plutôt un module "net" pour Nsetup qui interfacerait les commandes du
> système (ifconfig, ppp, ...).
Arfffff je dois reconnaitre avoir un peu ignoré cette approche.
Pour tout dire, ce qui me fait epur dans cette solution, c'est le fait
de couper Nsetup en deux entre un mode intercatif et un
non-interactif, alors que ce n'est pas du tout là sa vocation... De
plus, cela "mélangerat" d'autant interfaces/outils, ce qui n'est pas à
mon avis une bonne chose... à la limite on pourrait imaginer une arbo
interfaces/ et un /utils pourséparer les deux
--> à voir
> >INTERFACES GRAPHIQUES
> >
> >Ca y est, vous l'avez compris, nous sommes arrivés au coeur de la chose:
> >à partir de là, les suggestions sont de moi et ne doivent plus rien à
> >mes discussions avec Gontran et Azmodai:
> >N'hésitez donc pas à me remballer si nécessaire, je suis seul responsable
> >du contenu de cette section :-D
> >
> >L'un de buts de Nsetup est de proposer le maximum d'interfaces piour
> >répondre aux gouts de chacun: dans cette optique, nous avons comméncé
> >par vouloir partir sur l'utilisation d'une variable $DIALOG qui
> >pourrait avoir par valeur Zenity, Xdialog, Gdialog, Dialog...
> >
> >Cette solution ne me convient guère: en effet, elle oblige à se
> >restreindre au PPCD de touts ces alternatives, aux fonctions de abses,
> >sans pouvoir acceder à leurs spécificités. De plus, certaines
> >commandes comme Zenity admettent déjà une syntaxe clairement
> >différente même dans les bases incompatible avec cette approche.
> >
> >Je propose donc de mettre en place un système de frontal graphique dans
> >Nsetup,
> >afin de forunir un certian nombre de fonctions que les modules
> >pourront utiliser pour leur affichage sans se soucir le moins du monde
> >des détails de son implémentation: cette fonction do_dialog() serait
> >universelle et constiturait une sorte de "super-API", utilsable sur
> >absolement tous les Nsetup quelque soient les choix de l'utilsateur.
> >
> >Je prose maintenant de définir une fonction do_dialog() propre à
> >chaque solution, qui en exploite toute la syntaxe et les possibiltés:
> >une pour Zenity, une pour Xdialog, une pour un troisième système
> >etc...
> >toutes définies dans des scripts zenity.sh, xdialog.sh ...
> >situés dans backends/
> >
> >Nsetup decidera ensuite à l'éxecution laquelle "sourcer" zn fonction
> >du choix de l'utilisateur: il existerait ainsi des multiples variantes
> >de do_dialog(), dont une seule serait utilisée à la fois par Nsetup:
> >de meme que pour les modules, les alternatives disponibles pourront
> >très bien varier d'un système à l'autre, en fonction des gouts de
> >l'utilisateur.
> >
> >Je vois déjà les critiques arriver: pouquoi s'amuser à dupliquer des
> >fonctions pratiquement identiques, type celle de dialog et celle de
> >Xdialog ?
> >Tout d'abord, cette distinction n'a rien d'impérative:
> >on peut tout à fait regrouper dans un meme fichier les commandes qui
> >admetent strictement la meme interface, ma solution s'interessant
> >surtout à l'universalité et la flexibilité obtenue. De plus, un
> >copier-coller c'est plutôt rapide ;-)
> >
> >Ma solution permettrait surotut à Nsetup de supporter des outils
> >radicalement différents, sans renoncer à leurs avantages précis: cela
> >me semble une bonne chose, un frontal unifié et un backend spécifique
> >appelé en fonction :-)
> >
> >( Je dois reconnaitre m'etre pas mal inspiré de gcc :-D )
> Je te rejoins sur cette solution. J'apporterai tout de même quelques deltas
> :
>
> 1) en plus d'une fonction do_dialog, je me demande si il ne vaut mieux pas
> disposer d'une mutlitude de fonctions dans le style
> make_dialog_menubox_options, make_dialog_textbox_options,
> make_dialog_inputbox_options qui contruiraient les options spécifiques à
> chaque implémentation *dialog. Ce serait ces fonctions qui seraient
> redéfinies pour chaque implémentation.
>
> La fonction do_dialog ne serait implémentée qu'une seule fois. Elle
> ressemblerait à cela en pseudo-code :
>
> fonction do_dialog() {
> $DIALOG <tous les paramètres de la fonction>
> }
>
> Dans le code des modules, on écrirait :
> do_dialog `make_dialog_menubox Faites votre choix A Ajouter M Modifier S
> Supprimer`
>
> 2) Je pense qu'il est préférable que l'implémentation du dialog classique
> soit être sourcée systématiquement avant de sourcer l'implémentation du
> dialog spécifique. Ainsi, l'implémentation du dialog spécifique n'aurait
> qu'à définir les fonctions qui diffèrent du dialog classique.
>
> Pour ce qui est d'utiliser un autre lanqage que le bash et autre toolkit que
> *dialog, vous aurez compris que je n'y suis pas favorable. J'ai (au moins)
> deux arguments :
> - comme expliqué dans le paragraphe "Vocation de Nsetup", Nsetup fait appel
> à des commandes du système. Le meilleur langage permettant de s'interfacer
> avec le système reste pour moi le shell. Utiliser un autre langage rend les
> choses plus compliquées (pour le passage des arguments, pour la récupération
> de la sortie standard, ...).
> - il est vrai que *dialog ne permet pas de faire des interfaces graphiques
> très complexes. C'est justement sa moindre complexité qui apporte simplicité
> et clareté. De plus, Nsetup n'a pas pour but d'être utilisé tous les jours.
> Ce n'est pas comme si on devait coder une navigateur web.
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.
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...
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é...
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...
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 ).
@+
guiguilinux
