Je vais essayer d'expliquer le plus clairement possible ma proposition :-) :
Un module de Nsetup serait composé de deux parties :
- la commande : c'est la partie du module qui n'est pas visible, et qui ne
fait que réaliser un traitement pouvant utiliser ou non des informations
fournies par l'utilisateur ;
- l'interface graphique de la commande : c'est la partie visible du module.
Elle permet à l'utilisateur de fournir des données si c'est nécessaire, et
peut afficher des informations sur l'avancée ou le résultat du traitement de
la commande.
Un module serait donc composée d'une et une seule commande, et de une ou
plusieurs interfaces graphiques en Ncurses, Gtk+, Qt, etc.
Partant de ça, Nsetup serait constitué de 3 parties :
1- le script principal Nsetup
2- les commandes de Nsetup (la partie non visible des modules)
3- les interfaces graphiques des commandes
1 => le script principal serait chargé principalement d'analyser les
paramètres de la ligne de commande, d'initialiser le toolkit sélectionné et de lancer le module demandé.
Pour l'utilisation de Nsetup "hd" est-ce que le script principal serait
aussi chargé d'afficher un menu de navigation (afin de choisir son
module via une interface) lorsque aucun module n'est demandé en ligne de
commande ? Ou est-ce
que c'est un autre script qui est chargé de cela ?
2 => Il y aurait un fichier par commande. les commandes doivent pouvoir
réaliser un certain nombre de choses communes, comme par exemple afficher
leur interface graphique, ou encore lancer un sous-module ou un autre module
de Nsetup. Il faudrait que ces opérations soient clairement définies. Pour
cela, on pourrait créer une classe NsetupCommand qui serait héritée par
toutes les commandes, et qui définirait ces opérations communes. Par exemple,
il pourrait y avoir une méthode runCommandGui() pour afficher l'interface
graphique des commandes, une méthode runModule() pour lancer un autre module,
etc. Bien sûr, les commandes elles-mêmes n'auraient aucune idée de ce qui est
fait par ces méthodes. Tout serait transparent pour elles. Par exemple, une
commande qui appelle runCommandGui() saurait que l'interface qui lui
correspond serait affiché avec le toolkit choisi par l'utilisateur, mais
c'est tout. Cette méthode renverrait juste une référence vers un objet
correspondant à l'interface graphique, et permettant de récupérer les données
saisies par l'utilisateur et d'afficher des informations. Elle n'a nullement
besoin de savoir comment sont saisies ces données (champs textes, listes,
etc) ou comment sont affichées/présentées les informations. Elle doit juste
pouvoir les récupérer pour effectuer son traitement, par de simples appels de
méthodes.
3 => Comme dit précédemment, une commande peut avoir une ou plusieurs
interfaces graphiques développées avec un toolkit différent. A chaque
interface correspond un fichier.
Tout comme les commandes, les interfaces graphiques peuvent avoir un certain
nombre d'actions qui leur sont communes. Là encore, on pourrait définir une
classe NsetupGui héritée par toutes les interfaces graphiques. Elle pourrait
définir plusieurs méthodes comme getWindow() afin d'obtenir une référence sur
le widget dans lequel elles doivent se dessiner. Cela pourrait être utile
pour les sous-modules par exemple, qui pourrait dessiner leur interface dans
une partie de la fenêtre de leur module parent.
Ce serait la méthode runCommandGui() de la classe NsetupCommand qui se
chargerait de charger le script correspondant à l'interface de la commande
faite avec le toolkit sélectionné. Elle créerait alors une instance de cette
interface et en retournerait une référence pour la commande.
Voilà, je ne donne pas plus de détail pour ne pas me perdre en explication,
mais J'espère que c'est suffisamment clair :-) .
Est-ce que le principe vous convient ?
Bien moi ça me convient
++
