Bonjour, même si je ne suis pas très présent depuis le début du début
sur Nsetup2, je regarde les mails avec attention tous les jours.
Tout d'abord je pense que guiguilinux a tout à fait raison de demander
un choix. En effet le but est d'avancer sur Nsetup2 et avancer sur une
idée commune est toujours plus productif.
Pour moi l'idée d'avoir un Nsetup accessible par lignes de commandes
est vraiment une excellente idée. J'ai depuis le début des doutes sur
la possibilité d'obtenir un Nsetup en gtk et Ncurses tout en obtenant
un Nsetup utilisant le maximum de gtk et ncurses, et cela sans que les
modules ne soient trop « lourd » à coder. Cela est t'il vraiment
possible ?
Coder Nsetup en lignes de commandes permettrait d'avoir une base
commune (et aussi externe) contenant toutes les fonctions et le maximum
des possibilités de Nsetup. Ensuite les interfaces ne feraient
qu'essayer de faire « passer » ça le mieux possible à l'écran (On ne
peut déjà pas avoir un Nsetup-gtk identique à Nsetup-ncurses sans
réduire les possibilités de Nsetup).
Bref , pour moi un Nsetup en lignes de commandes + un Nsetup en gtk
m'auraient suffit. Cela se rapproche d'avantage de la solution de
guiguilinux -> donc je suivrais d'avantage guiguilinux dans ses idées.
Voilà pour mes idées...
geekitus
On Mon, 27 Jun 2005 16:20:23 +0200
Laville Guillaume <[EMAIL PROTECTED]> wrote:
> Bonjour tout le monde
>
> Ce débat est destiné à l'ensemble des membres du projet,
> et meme à ceux qui n'en feraient par partie.
>
> Nous sommes tombés d'accord sur un certain nombre
> de chose dans notre équipe pour le prochain Nsetup:
> interface GTK2 et Curses, modularité.
>
> Mais il se pose maintenant le problème de l'architecture global.
> Au fil de notre débat, trois architectures possivles nous sont
apparues.
>
> - d'abord celle de Leif-, qui consite à créer une couche d'abstartion
Ngui,
> par dessus les bibilothèques GTK2, curses, QT, etc... cette solution
> présente l'avantage de la plus grande failité pour le développeur, car
> celui-ci peut programmer son module sans se soucier de l'interface
> utilisée, et faire quelque chose de réellement universel...
>
> Cependant, la création d'une telle librairie est utopique, ou sera au
> mieux tres dificille et le résultat peu satisfaisant : les toolkits
> ont des foules de spécificctés, de tournures propres que nous en
> pourron pas prendre en compte, et nous riquons d'aboutir à une sorte
> de nouveau *dialog à la sauce ruby, tres simple mais aussi extremement
> limité.
>
> - ZEnsuite Gontran nous a suggeré une nouvelel idée: un Nsetup
> modulaire, mais ou chaque module serait eclaté en une partie
> "commande", qui effectuerait la tache du module proprement dite, et
> autant de parties "interfaces" qu'il y aurait de toolkit utilisés :
> une pour GTK2, une pour Curses... La bonne interface serait chergée au
> lancement du module.
>
> Je ne peut personnelement pas contiauner cette voie: en effect cela
> implique de se programmer le moindre bout d'interface en deux, mais
> qui sait un jour trois ou quatre ou plus d'exemplaires... de plus, la
> connection entre le aprtie commande est la partie interface sera à mon
> avis assez délicate: enfin, ce qui me fait surtout peur, c'est la
> complexité et la coté "tout en un" de la solution de gontran: le tout
> rique de devenir rapidement incompréhensible sauf aux developpeurs
> chevronnés, et je ne supporterait pas de sacrifier l'un des idéaux de
> Nasgaia, la simplicité, sur l'autel de Nsetup: Nsetup doit rester
> accessible aux debutants, sous peine de perdre tout ce qui fait son
> originalité et devnir un enimeme drakconf ou Yast, des utilitaires qui
> marchent tres bien mais auquel jaimais personne n'osera toucher au
> code, reservé à une team de geek...
>
> - La dernière solution est de moi: elle s'inspire de l'organisation
> d'un grand nombre d'outils UNIX ou Linux, comme apt-get, et a fait ces
> preuves:c'est à mon avis la meilleure, à la fois du point de vue
> puissance et clareté: l'objectif de base peut etre résumer en deux
> points: fournir des outils de configuration qui manquent,
> et une interface commode pour les utiliser ainsi que les existants.
>
> Mon idée est simple: partagons les roles !
>
> Créons un Nsetup en ligne de commande, voire meme en ensemble de petit
outils,
> qui permettent des combler les lacunes en termes de configuration d'un
> linux standard...
>
> Et rajoutons par dessus des interfaces graphiques pour les exploiter:
> ainsi, les deux aspects de Nsetup seraient clairement dissociés,
> et nous y gagnerions en clareté mais aussi en flexibilité.
>
> En effet, en utilisant qui ressemble à ce que fait synaptic par
rapport
> à dpkg, GParted par rapport à Parted, rien ne devient plus facile que
> de créer une nouvelle interface, ou de faire évoluer chaque interface
> pour exploiter au mieux son tollkit !
>
> Comme vous le voyez, nous avons donc plusieurs alternatives....
> Nous serions plutot, dans l'équipe de Nsetup, pour la dernière
approche,
> à l'exception de Leif- qui défend la solution de gontran.
>
> Mais j'estime que sur de telles point ce n'est pas à nous de decider
> en leiu et place des autres Nasgaiens: vous allez utiliser ce nouvel
> Nsetup comme nous, et il est normal que vous ayez votre mot à dire.
>
> Je suis pour la troisième solution.
> Non pas parce qu'elle est la mienne
> mais parce que la première est techniquement irréalisable à mon avis
> et la seconde implique de sacrifier ce à quoi je tiens le plus dans
Nsetup,
> sa simplicité et son conté humain.
> j'irais jusqu'à dire que cette solution viole une partie de la charte,
> mais c'est aux Nasgaiens de décider...
>
> J'attends donc tous vos avis,
> au nom du prochain Nsetup
>
> @+
> guiguilinux,
> responsable de Nsetup
>
> _______________________________________________
> Nasgaia-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/nasgaia-dev
