Le Lundi 13 Juin 2005 06:03, Leif Thande a écrit : > Je veux bien oublier l'idée d'utiliser Ngui, mais alors on fait > comment ? On refait chaque module pour chaque interface ? On sépare > l'interface de chaque module dans un fichier annexe ? Ça me semble un > peu répétitif pour rien, mais bon ce serait surement plus rapide que > d'apprendre un nouvel interface intermédiaire. As-tu une idée à nous > proposer ?
Salut Leif, 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é. 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 ? ++ Gontran
