GUI : pourquoi pas kiwi ?

Bonjour,
speedy73 wrote:

Je suis un petit jeune de python, sensible en plus, et je vous remercie
de vos points de vue éclairés et surtout éclairants: j'espère... :)
Tout le problème est que avant d'avoir un point de vue lumineux il faut

commencer par apprendre à s'en servir, + probablement glade, +
probablement gtk, et sans doute dans l'ordre inverse. Bien intéressant
mais diablement couteux en temps, donc inadapté en ce qui me concerne.
Je préfère rester sur wx, avec ou sans boa.
Après lecture rapide de la doc, la structure est tentante, mais j'ai
l'impression qu'il n'y a pas beaucoup de widgets supportés (pas de
treeview par exemple).
A+
jm

jean-michel bain-cornu wrote:

Bonjour,
speedy73 wrote:

Je suis un petit jeune de python, sensible en plus, et je vous
remercie de vos points de vue éclairés et surtout éclairants:
j'espère... :)
Tout le problème est que avant d'avoir un point de vue lumineux il faut

commencer par apprendre à s'en servir, + probablement glade, +
probablement gtk, et sans doute dans l'ordre inverse. Bien intéressant
mais diablement couteux en temps, donc inadapté en ce qui me concerne.
Je préfère rester sur wx, avec ou sans boa.
Après lecture rapide de la doc, la structure est tentante, mais j'ai
l'impression qu'il n'y a pas beaucoup de widgets supportés (pas de
treeview par exemple).
A+
jm
C'est vrai que c'est pas aussi abouti que wxPython (sauf au niveau doc

ou c'est au moins équivallent :).
PythonCard à peut-être un esprit un peu similaire et est sans doute plus
avancé...

Bon c'est au niveau d'abstraction/perf que ça joue non ? La
représentation suivante semble-t-elle juste.

GTK | c | --> pygtk --> glade ou gazpacho --> code
--> kiwi
---------------------> Pas d'outil style Boa

| c | --> wx --> wxPython --> wxGlade --> code
--> pythonCard
---------------------> Boa

Bonjour,
speedy73 wrote:

Je suis un petit jeune de python, sensible en plus, et je vous
remercie de vos points de vue éclairés et surtout éclairants:
j'espère... :)
Tout le problème est que avant d'avoir un point de vue lumineux il fa ut

commencer par apprendre à s'en servir, + probablement glade, +
probablement gtk, et sans doute dans l'ordre inverse. Bien intéressan t
mais diablement couteux en temps, donc inadapté en ce qui me concerne .
Je préfère rester sur wx, avec ou sans boa.
Après lecture rapide de la doc, la structure est tentante, mais j'ai
l'impression qu'il n'y a pas beaucoup de widgets supportés (pas de
treeview par exemple).
A+
jm
Personnellement aucun des gui que j'ai pu regarder ne me satisfait

complètement. en fait j'aimerais avoir :
- un découplage complet entre le moteur (l'application) et l'interface
utilisateur
- un fonctionnement de type langage acteur
- la possibilité de charger une interface à la xul
- une interface totalement skinable par un mécanisme style feuille de s tyle
- la disponibilité d'un gui builder
- ne pas avoir à programmer des callback pour gérer les saisies de pa ramètre
- un fonctionnement en client serveur entre l'appli et son interface

En fait le modèle des form html me convient presque et il y a peut êt re
des petits espoirs du coté de XUL mais pas à la manière de nufox.
L'interface utilisateur doit pouvoir être bâtie sans écrire une lig ne de
code.

Pensez vous que je délire ?

Personnellement aucun des gui que j'ai pu regarder ne me satisfait
complètement.

C'est marrant, pour notre application (un gros machin bancaire) nous
avons fait le même constat, mais avec des besoins un peu différents.

en fait j'aimerais avoir :
- un découplage complet entre le moteur (l'application) et l'interface
utilisateur
- un fonctionnement de type langage acteur
- la possibilité de charger une interface à la xul
- une interface totalement skinable par un mécanisme style feuille de style

OK pour tout (si j'ai bien compris 'langage acteur' et 'une interface à
la xul'. Peux-tu préciser ?)

- la disponibilité d'un gui builder

J'ai aussi envie d'ajouter l'opposé: le code doit pouvoir être maintenu
par un simple éditeur.

- ne pas avoir à programmer des callback pour gérer les saisies de
paramètre
- un fonctionnement en client serveur entre l'appli et son interface

En fait le modèle des form html me convient presque et il y a peut être
des petits espoirs du coté de XUL mais pas à la manière de nufox.
L'interface utilisateur doit pouvoir être bâtie sans écrire une ligne de
code.

Mais il faut aussi ajouter:
- si je veux écrire une ligne de code (pour une appeler ma super
fonction de vérification de la saisie qui est déjà écrite en C), il faut
que ce soit simple.

Pensez vous que je délire ?

Le beurre et l'argent du beurre.

En fait, nous avons déjà commencé un mécanisme de ce type qui
fonctionne. Evidemment, nous avons écrit tout le framework...
Je ne peux malheureusement pas partager le code (qui est trop lié à
notre application de toute façon), mais voici quelques caractéristiques:

- 90% de nos écrans manipulent les éléments d'une base de données. Le
fonctionnement typique est de présenter une liste d'éléments ; Un
double-clic permet de modifier les propriétés.
- Il y a plus de 1000 écrans de ce type !

- En une classe, on décrit la liste, ET la boîte qui suit. C'est du
code, mais en fait c'est plus une description statique de l'écran.

- L'affichage et le fonctionnement de l'écran est totalement délégué à
un "moteur". Nous avons déjà plusieurs moteurs : un pour wxPython, un en
'mode texte' (un vieux windows manager sous Ms/Dos, qui ressemble un peu
à ceci http://www.icewalkers.com/scrshot/975/).

- La disposition à l'écran se fait automatiquement. Par défaut, c'est un
simple formulaire ; mais on peut positionner les éléments si nécessaire
(avec un formalisme qui ressemble à reST:
http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables)

- Le lien avec la base de données est soit automatique (si les champs
ont les noms des colonnes SQL) mais c'est rare, soit manuel (de toutes
façons, tous nos développeurs sont bilingues python/SQL)

- On utilise la 'magie' de python quand c'est nécessaire. Par exemple,
les champs sont dans l'ordre où ils apparaissent dans le code ; c'est la
présence ou non de la méthode onDelete qui indique si on gère la
suppression d'un élément...

Et un exemple complet d'écran simple qui marche!

class Employee(SimpleDialog):
title = "Employees"

def defineFields(self):
self.emp_id = NumericField("ID",enable=self.whenInserting)
self.name = TextField("Name",size0)
self.manager_id = ListField("Manager",showColumns=(2,))
self.manager_id.choices = self.stmt(
"SELECT EMP_ID,NAME FROM EMP WHERE EMP_ID!=:emp_id")

def getItems(self):
return self.stmt("SELECT EMP_ID,NAME,MANAGER_ID,ROWID FROM EMP")

def onInsert(self):
self.sql("INSERT INTO EMP VALUES (:emp_id, :name, :manager_id)")

def onUpdate(self):
self.sql("UPDATE EMP SET NAME=:name, MANAGER_ID=:manager_id)")


J'aime cette méthode qui ne sépare pas complètement les données de la
présentation, mais qui s'en tient au minimum pour qu'un framework
'intelligent' en fasse une présentation soignée, cohérente pour toute
l'application, et qui marche.

Il est ainsi possible (en théorie) d'écrire un 'moteur' qui génère du
HTML/javascript, et qui effectue côté serveur les actions que le browser
ne peut pas faire. Le même code peut aussi s'insérer dans un serveur
SOAP, par exemple.

Bon, j'ai été trop long, je m'arrête...

--
Amaury

jean-michel bain-cornu wrote:

Bonjour,
speedy73 wrote:

Je suis un petit jeune de python, sensible en plus, et je vous
remercie de vos points de vue éclairés et surtout éclairants:
j'espère... :)
Tout le problème est que avant d'avoir un point de vue lumineux il faut

commencer par apprendre à s'en servir, + probablement glade, +
probablement gtk, et sans doute dans l'ordre inverse. Bien intéressant
mais diablement couteux en temps, donc inadapté en ce qui me concerne.
Je préfère rester sur wx, avec ou sans boa.
Après lecture rapide de la doc, la structure est tentante, mais j'ai
l'impression qu'il n'y a pas beaucoup de widgets supportés (pas de
treeview par exemple).
A+
jm

Bon, pour les widgets, je crois que le mieux est de regarder la doc de
l'api pour trouver à "kiwi.ui.widgets.list"

- "An enhanced version of GtkTreeView, which provides pythonic wrappers
for accessing rows, and optional facilities for column sorting (with
types) and column selection."

En parcourant la liste, il me semble qu'il ne manque pas beaucoup.....
Si on travaille avec libglade et donc gaspacho il faut utiliser un kiwi
widget/ Object List (enfin, je crois)...

Pour ce qui est de la rapidité, le MVC coûte certainement un peu... On
peut toujours descendre si nécessaire d'une ou plusieurs couches.

Par rapport à "Python card", il me semble qu'il y a une couche de moins
(il est très possible que je me trompe: rectifier SVP).
PythonCard est un niveau d'abstraction supplémentaire par rapport à
wxPython qui utilise lui-même GTK, alors que Kiwi est une couche qui
utilise directement GTK, tjs d'après ce que j'ai compris et est
certainement discutable...

Amaury Forgeot d'Arc wrote:

Personnellement aucun des gui que j'ai pu regarder ne me satisfait
complètement.

C'est marrant, pour notre application (un gros machin bancaire) nous
avons fait le même constat, mais avec des besoins un peu différents.

en fait j'aimerais avoir :
- un découplage complet entre le moteur (l'application) et l'interface
utilisateur
- un fonctionnement de type langage acteur
- la possibilité de charger une interface à la xul
- une interface totalement skinable par un mécanisme style feuille de
style

OK pour tout (si j'ai bien compris 'langage acteur' et 'une interface à
la xul'. Peux-tu préciser ?)

- la disponibilité d'un gui builder

J'ai aussi envie d'ajouter l'opposé: le code doit pouvoir être maintenu
par un simple éditeur.

- ne pas avoir à programmer des callback pour gérer les saisies de
paramètre
- un fonctionnement en client serveur entre l'appli et son interface

En fait le modèle des form html me convient presque et il y a peut
être des petits espoirs du coté de XUL mais pas à la manière de nufox.
L'interface utilisateur doit pouvoir être bâtie sans écrire une ligne
de code.

Mais il faut aussi ajouter:
- si je veux écrire une ligne de code (pour une appeler ma super
fonction de vérification de la saisie qui est déjà écrite en C), il faut
que ce soit simple.

Pensez vous que je délire ?

Le beurre et l'argent du beurre.

En fait, nous avons déjà commencé un mécanisme de ce type qui
fonctionne. Evidemment, nous avons écrit tout le framework...
Je ne peux malheureusement pas partager le code (qui est trop lié à
notre application de toute façon), mais voici quelques caractéristiques:

- 90% de nos écrans manipulent les éléments d'une base de données. Le
fonctionnement typique est de présenter une liste d'éléments ; Un
double-clic permet de modifier les propriétés.
- Il y a plus de 1000 écrans de ce type !

- En une classe, on décrit la liste, ET la boîte qui suit. C'est du
code, mais en fait c'est plus une description statique de l'écran.

- L'affichage et le fonctionnement de l'écran est totalement délégué à
un "moteur". Nous avons déjà plusieurs moteurs : un pour wxPython, un en
'mode texte' (un vieux windows manager sous Ms/Dos, qui ressemble un peu
à ceci http://www.icewalkers.com/scrshot/975/).

- La disposition à l'écran se fait automatiquement. Par défaut, c'est un
simple formulaire ; mais on peut positionner les éléments si nécessaire
(avec un formalisme qui ressemble à reST:
http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables)

- Le lien avec la base de données est soit automatique (si les champs
ont les noms des colonnes SQL) mais c'est rare, soit manuel (de toutes
façons, tous nos développeurs sont bilingues python/SQL)

- On utilise la 'magie' de python quand c'est nécessaire. Par exemple,
les champs sont dans l'ordre où ils apparaissent dans le code ; c'est la
présence ou non de la méthode onDelete qui indique si on gère la
suppression d'un élément...

Et un exemple complet d'écran simple qui marche!

class Employee(SimpleDialog):
title = "Employees"

def defineFields(self):
self.emp_id = NumericField("ID",enable=self.whenInserting)
self.name = TextField("Name",size0)
self.manager_id = ListField("Manager",showColumns=(2,))
self.manager_id.choices = self.stmt(
"SELECT EMP_ID,NAME FROM EMP WHERE EMP_ID!=:emp_id")

def getItems(self):
return self.stmt("SELECT EMP_ID,NAME,MANAGER_ID,ROWID FROM EMP")

def onInsert(self):
self.sql("INSERT INTO EMP VALUES (:emp_id, :name, :manager_id)")

def onUpdate(self):
self.sql("UPDATE EMP SET NAME=:name, MANAGER_ID=:manager_id)")


J'aime cette méthode qui ne sépare pas complètement les données de la
présentation, mais qui s'en tient au minimum pour qu'un framework
'intelligent' en fasse une présentation soignée, cohérente pour toute
l'application, et qui marche.

Il est ainsi possible (en théorie) d'écrire un 'moteur' qui génère du
HTML/javascript, et qui effectue côté serveur les actions que le browser
ne peut pas faire. Le même code peut aussi s'insérer dans un serveur
SOAP, par exemple.

Bon, j'ai été trop long, je m'arrête...

Ca me semble intéressant, et complémentaire!

En fait, ne faudrait-t-il pas de Frameworks métiers? On définit des
besoins, des contraintes fonctionnelles ce qui permet d'avoir des
modèles objet très ciblés, pas forcément incompatibles avec une approche
"Modèle Vues Contrôleurs" mais nécessitant parfois des compléments au
niveau des couches fonctionneles: applis web, distribuées etc...

En gros, à partir d'un même "Modèle" et d'une même ... template ?.... on
définit différentes implémentations des vues et des contrôleurs selon le
contexte applicatif ?

speedy73 wrote:

Par rapport à "Python card", il me semble qu'il y a une couche de moins
(il est très possible que je me trompe: rectifier SVP).
PythonCard est un niveau d'abstraction supplémentaire par rapport à
wxPython qui utilise lui-même GTK, alors que Kiwi est une couche qui
utilise directement GTK, tjs d'après ce que j'ai compris et est
certainement discutable...
Juste une précision : wx n'utilise pas forcément gtk.

OK pour tout (si j'ai bien compris 'langage acteur' et 'une interface à
la xul'. Peux-tu préciser ?)

En fait j'imagine quelque chose comme l'application s'adressant à
l'acteur interface en lui disant become(tel_ecran) l'utilisateur fait ce
qu'il a à faire, l'essentiel des actions n'agissent que sur le vecteur
de paramètres de l'interface et d'autre déclenchent l'envoi d'un mess age
vers l'application send(action,vector).
Bien sur l'interface ne serait pas forcément sur la même machine.
C'est très mal exprimé mais c'est l'idée

par a la xul je voulais dire que le paramètre du become serait l'URI
d'un fichier contenant un objet sous forme xml (ou autre) définissant
l'ensemble de l'interface et de ses interactions.

Personnellement aucun des gui que j'ai pu regarder ne me satisfait
complètement. en fait j'aimerais avoir :
- un découplage complet entre le moteur (l'application) et l'interface
utilisateur
- un fonctionnement de type langage acteur
- la possibilité de charger une interface à la xul
- une interface totalement skinable par un mécanisme style feuille de style
- la disponibilité d'un gui builder
- ne pas avoir à programmer des callback pour gérer les saisies de
paramètre
- un fonctionnement en client serveur entre l'appli et son interface

Ce que tu veux c'est XUL, alors utilise XUL.

Bertrand B wrote:

OK pour tout (si j'ai bien compris 'langage acteur' et 'une interface à
la xul'. Peux-tu préciser ?)

En fait j'imagine quelque chose comme l'application s'adressant à
l'acteur interface en lui disant become(tel_ecran) l'utilisateur fait ce
qu'il a à faire, l'essentiel des actions n'agissent que sur le vecteur
de paramètres de l'interface et d'autre déclenchent l'envoi d'un message
vers l'application send(action,vector).
Bien sur l'interface ne serait pas forcément sur la même machine.
C'est très mal exprimé mais c'est l'idée

par a la xul je voulais dire que le paramètre du become serait l'URI
d'un fichier contenant un objet sous forme xml (ou autre) définissant
l'ensemble de l'interface et de ses interactions.

Tu veux donc un truc comme qtui qui charge directement les fichiers .ui
créés avec qtdesigner ou libglade qui fait l'equivalent pour pygtk ?