> Je suis désolé de ne pas adhérer à cette proposition :-), mais je pense > sincèrement que ce n'est pas la bonne solution. La différence entre les > toolkits fait que à un moment ou à un autre, on risque d'aboutir dans un cul > de sac. Il vaut mieux laisser un libre accès direct aux différents toolkits. > > Prenons qqs différences tout bêtes entre Gtk et Qt : les widgets de Gtk n'ont > pas la notion de «parent» dans leur constructeur alors que ceux de Qt > l'ont, le positionnement de widgets avec Qt peut utiliser la notion de > «spacer» (élément vide de séparation) qui ne me semblent pas exister avec > Gtk+ ... comment gérer toutes ces différences ? Chaque ajout de toolkit à > Nsetup risque d'obliger à revoir à chaque fois la manière de créer les > widgets et celle de positionner les éléments. Je pense honnêtement qu'il est > plus simple d'utiliser directement chaque toolkit.
Bonjour tout le monde. Comme vous avez pu le lire sur cette mailing list, Leif- et moi nous sommes lancés dans des tests prélimianires de Nsetup pour voir ce qu'il marchait le mieux. Personnellement, j'en ai déjà tiré quelques grandes conclusions: Si jamais on choisit ma voie ou celle de gontran, on va se retrouver avec un code monstreux: notre Nsetup sera effetcivement une merveille mais hors de porter du gentil dev de module qui voudra apporter sa pierre à l'ensemble: celui-ci va devoir se coltiner en dur tout le code, sans parler de l'internationnalisation... Les seuls qui pourront avoir une chose de faire quelque chose devront connaitre Ruby, GTK2 et curses sur le bout des doigts :-( Notre optique actuelle de Nsetup me semble aboutir sur une impasse: le Nsetup obtenue sera beau sans aucun doute, mais reservé aux geek pur et dur qui sait s'y retrouver dans des quantités monstrueuses de code: Je ne sait pas pour Leif-, mais personnelement meme en utilisant Glade (ce qui rajoute des deps et donc que je n'aime guere), on aboutit à un résultat qui n'est guere mieux... Gontran, tu justifie ton approche par la fait qu'un Ngui serait trop limitatif: mais est-ce que le concepteur de module moyen va réellement utiliser des fonctions spécifiques pour écrire son module, surtout s'il s'agit d'un dev de base ? Mais cela limiterait la liberté du dev, au profit de la facilité et ce n'est pas forcément mieux comme ça... C'est là que jean-mi nous à trouvé la solution ultime: l'idée serait de revenir à notre architecture de départ basée sur Ngui, avec sa simplicité et ses facilités multi-interfaces, tout en laissant la possibilité au dev de module de rajouter lui meme ses extensions à Ngui, ses fonctions de son cru. Vu le code que j'ai obtenu avec mes quelques essais en suivant les autres pistes, c'est la seule solution qui permettrait d'aboutir à un Nsetup qui reste humain sans trop sacrifier en puissance pour le dev... Je propose de repartir dans cette optique pour Nsetup... @+ guiguilinux
