Bonjour tout le monde

Et oui, voilà que je redeterre un topic que tous croyaient (esperaient?)
enterré...

La base de Nsetup est maintenant pratuqiement terminée,
en utilsant bash/*dialog.

Et, une fois de plus, je me casse les dents sur les maigres possibilités
des *dialog: pour un petit script, c'est un moyen simple et rapide
de se faire un petite interface graphique.

Mais pour Nsetup, j'ai peur :-|

Il est absolument impossible avec un *dialog de
faire quoique ce soit d'autre que des fenetres avec UN menu,
UNE barre de progression, etc...

Bref, on perd tout l'interet des interfaces actuelles
qui permettent de combiner boutons, images, menus
et barre de progression dans une seule fenetre:

Mainteant je ne le crois plus, j'en suis sûr:
les *dialog exisatnts sont beaucoup trop limités si nous voulons faire
quoique ce soit d'innovant ou meme de simplement interessant pour Nsetup...

jean-mi et moi en avons parlé,
et il m'a suggerré de réécrire mon nxdialog perso qui permettrait
de personanliser le contenu de ses fenetres, leur position etc...

Cependant cela reviendrait à écrire toute une interface gtk2 pour bash,
avec toutes les possibilités ou presque du toolkit,
sous peine de se heurter de nouveau un peu plus loin au meme limites
qu'avec *dialog

Vous vous voyez programmer gtk2 en bash ?
Moi non. En admettant qu'une telle adaptaion soit possible,
cela impliquerait un tel nombre de bricolage bancals et
de myens detournés que le tout deviendrait impraticable...

Au contraire, Python et Ruby conviendrait à merveille
pour réaliser notre Nsetup de reve,
comme l'ont si bien souligné chicha et gontran:
clairs, lisibles, puissant tout en restant abordable.

Le dernière fois, j'avait suggeré python
en n'étudiant pas à fonc la question.
Cela m'avait amené à une recul vers bash
assez peu glorieux et qui ne resoud rien.

J'ai donc regardé de plus pres nos deux challenger,
python et ruby, notamment au niveau de la gestion des interfaces.

Et ce que j'y ai vu m'a rassuré:
je me suis mis à pygtk, et ce n'est pas aussi terrible que ça en à l'air:
en tout cas moins à mion avis que de reprogrammer Nxdialog en C,
et la puissance en est incomparable.

J'était pres à voter python pour Nsetup sans hésiter,
mais les propos de chicha ont attiré ma curiosité sur ruby,
un langage que je ne connaissait pas et dont chicha faisait de
grands éloges.

Je suis donc parti à la chasse au ruby.

J'y ai trouvé à langage orienté objet clair,
sans bavure, qui, sans ceder à la compexité inutile,
renvoie les autres langages et leur syntaxe alambiquée à l'age de pierre,
python dans une moindre mesure.

Il offre des methodes de manipulation de chaine assez bluffantes,
de meme que pour les tableaux,
mais il reprend surtout les expressions regulieres de Perl,
bien connues pour leur puissance ;-) 

Il s'interface aussi à merveille avec gtk, curse, qt...
J'ai essayé d'y programmer une double barre de progression:
c'est le reve ! Aucun argument "magqiueé, ou bizarre,
veant d'on ne sait ou, une simplicité deconcertante.

Meme python n'arrive pas à faire ausi bien,
avec ses "self", "NULL", "widget" omnipresents dans les appels de fonctions:
en ruby, vous ne mettez QUE ce dont vous avez besoin, et vous obtenez
un code pour lequel les commentaires sont de l'ordre de la fioriture ;-)

Je vous jopint par exemple mon premier essai de double barre de progression:
je défie qui que ce soit de faire plus simple,
et plus lisible, dans le langage de votre choix: et ce code n'est meme
pas commenté ;-)

Donc, apres examen de ces deux alternatives,
je rejoint chicha. En tant que developpeur de Nsetup,
si j'ai mon mot à dire, je vote ruby

Un langage encore assez peu connu, mais l'outsider ultime,
avec python une caroote derriere ;-P

Ce langage combine le meilleur de smalltalk, perl et python:
Pur objet, puissance et simplicité, lisibilité

Il offre tous les outils pour faire un Nsetup
inoubliable, et d'une clareté incomparable...

Je n'ai qu'une chose à vous remmander:
pour ceux qui ne l'ont pas encore fait, essayez-le ;-)

@+
guiguilinux

Attachment: doublebarre.rb
Description: Binary data

Répondre à