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.
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.
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, ...).
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.
Je suis impatient de connaitre votre avis sue la question
Tu as maintenant mon avis. ;)
@+
guiguilinux
--
Julien
_________________________________________________________________
MSN Messenger : personnalisez votre messagerie instantanée !
http://g.msn.fr/FR1001/866
