[PyMUI] – Alpha release

[Yomgui]

Yomgui

#5137

Pour ceux qui n’étaient pas à l’Alchimie7 (et pour ceux qui y étaient mais qui n’ont rien vu ), j’ai conçu (enfin un début…) ce que j’avais annoncé sur mon blog: un module Python pour créer des interfaces graphiques MUI en Python donc.

La première partie est faite: créer/détruire un objet MUI , encapsulé dans un objet Python, pouvoir faire des DoMethod, ainsi que notifications. Cela fonctionne comme l’on pu en voir certains à l’Alchimie.

Maintenant cette couche n’a aucune notion de l’utilité des objets (c’est quoi une classe? c’est quoi une fenêtre, un ‘slider’? etc). C’est là qu’intervient une deuxième couche que je suis en cours de construction. C’est cette couche que verra l’utilisateur de mon module. Elle sert donc à abstraire et simplifier l’API de MUI.

J’en viens donc au sujet de ce fils. J’aimerai savoir des futurs intéressés:

* Si ils programment déjà en MUI/C:

– Qu’est-ce qu’il trouve de complexe l’utilisation de MUI?

– Qu’est-ce qu’il trouve de simple dans MUI et qu’ils aimeraient voir dans ce module?

* Si ils ne programment pas en MUI/C ou qu’ils n’ont jamais programmé en C:

– Pourquoi ne pas avoir encore touché à MUI?

– Qu’est-ce qu’ils trouvent comme barrières à se mettre à la programmation en C?

– Connaissent-ils le Python et/ou les langages dits ‘Scripts’?

N’hésitez pas à mettre votre grain de sel à ce projet.

Et n’oubliez pas que les programmeurs ont besoins de vous les utilisateurs pour concevoir des choses utilisables.

Merci.

[SixK]

SixK

#87916

Ha si seulement tu faisais la meme chose pour PHP !

PHP me parait plus facile d’acces que Python, ceci dit ton module Python est une tres tres bonne nouvelle !

SixK

[corto]

corto

#87917

Python, Ruby, … c’est la simplicité du basic, la puissance de l’objet, la portabilité, …

MUI, le C, … tout ça demande beaucoup de temps pour l’apprentissage et certains veulent programmer des choses simples sans se prendre la tête.

Ce que propose Yomgui est ce que certains attendaient depuis longtemps ! Et à ce niveau-là, je trouve que c’est une preuve de maturité. Il n’y a plus d’excuses pour ceux qui se plaignaient que la programmation c’est difficile (récupérer le SDK, trouver dans quelle bibliothèque se trouvent les fonctions dont on a besoin, galérer avec les pointeurs, …).

Bravo Yomgui !

SixK : Hum … PHP a du succès parce qu’il était plus simple que d’autres technos pour le web. Et puis quelle facilité pour interfacer une base MySQL. Par contre, je trouve que c’est vraie galère : pas orienté objet, une API pourrie, une médiocre lisibilité … C’est mon coup de gueule : PHP c’est du bricolage. Qui permet, c’est vrai, de faire des tas de choses et a démocratrisé la programmation web.

Je ne veux pas faire de débat sur les langages. Yomgui se décarcasse, il a tout compris, il mérite qu’on s’intéresse à son wrapper Python/MUI.

Yomgui : Tu pourrais poster un exemple pour montrer la simplicité de la chose.

[M_o_Illusion]

M_o_Illusion

#87918

Functional example:

from mui import *

# Creating a new main window with a simple text gadget

win = Window(RootObject=Text(Content=’Hellow world!’))

# Now creating the application

app = Application(

Version = « $VER: PyMUITest 0.1 (06.06.07) »,

Copyright = « (C)2007, Yomgui »,

Author = « Yomgui »,

Description = « PyMUI test »,

Base = « PYMUITEST »)

# … and link your window to it

app.AddWindow(win)

win.Open = True # it’s like a classical MUI attribute access

# Run !

app.mainloop()

Pris sur le blog de Yomgui.

[Yomgui]

Yomgui

#87919

@Corto: Voilà, comme le dit M_Of_Illusion

Comme je le dis aussi sur mon blog, je souhaite garder les 2 façons de

programmer de Python: fonctionnelle et objet.

L’exemple donné est l’aspect « fonctionnel ».

Ensuite on peut aussi le faire de façon objet avec des classes et

tout…

Mais pour l’instant la couche « haute » me donne du travail

Surtout les moultes structures (MUI comme système)

[corto]

corto

#87920

Yomgui : Vu tes compétences, je parie pour que tu vas réussir à obtenir quelque chose qui déchire et qui reste simple. Dans le principe :

window = Window(…)

window.AddButton(« Vive l’Alchimie »)

app.AddWindow(window)

app.Open()

Et hop, on a une fenêtre en 4 lignes !

A mon avis, il faut voir à quoi ça va être utilisé en faisant oublié MUI, quitte peut-être à laisser tomber quelques raffinements. MUI tel qu’on peut l’utiliser en Blitz, en ARexx, … c’est bien mais il manque en effet une couche de plus haut niveau.

J’y pense : il doit déjà y avoir des classes Python qui gère la GUI, non ? Dans ce cas, peut-on garder la même API et en-dessous, pour nous, c’est du MUI mais l’utilisateur s’en fiche. Ca pourrait permettre d’utiliser des programmes graphiques en Python qui existent déjà.

Ou alors il y a juste des wrappers bas niveau pour WxWidgets, GTK, … ?

Mince, je me suis trahi … je n’étais pas allé sur le blog … /

[Yomgui]

Yomgui

#87921

@Corto: effectivement je n’avais pas pensé à utilisé mon module et l’API de WxPython pour faire qq chose compatible.

Ca peut amener des applis… enfin souvent une appli n’est pas faite que d’une GUI, il y aura toujours des dépendances non résolues.

[M_o_Illusion]

M_o_Illusion

#87922

J’aime bien ton code de principe, Corto, ca donne envie ^^

[BatteMan]

BatteMan

#87923

Alors, comme je suis hautement intéressé par ce module, n’ayant jamais eu le courage d’aller plus loin que les 20 premières pages du Kernighan&Ritchie… Alors, comme pour tripoter MUI, il faut toucher au C (ou à MUIRexx, mais je ne trouve pas ça hyper « performant » même si de chouettes choses sont faites en MUIRexx), je n’ai jamais dépassé les premiers tutos MUI… oui, honte à moi…

Pour moi, le C semble assez « difficile » au départ (comprendre ce qu’on fait surtout)… Quant à Python, le peu que j’en ai vu me semblait plus « clair » et « lisible » donc plus compréhensible. Mais je suppose que comme l’approche n’est pas la même, on ne peut pas les comparer.

Bref, un post pour pas dire grand chose, mais je me devais de participer à ce fil de discussion.

—

/me se le devait.

Only Amiga makes it possible !

[bigdan]

bigdan

#87924

J’ai vu une petite démo à l’Alchimie, cela donne envie et me rappelle furieusement mes premiers essais MUI en E il y a quelques années…

Et comme je fais justement des petits essais en C, je vais pouvoir comparer avec la version PyMui

Yomgui merci à toi encore un fois (pour Python et Blender surtout),

Arnaud alias bigdan

qui passait par là…

[Yomgui]

Yomgui

#87925

Bon j’ai fait le tri…

Il y aura des classes qui ne seront pas supportées, car redondantes avec Python, genre ‘Semaphore’ & Co.

Tout ce qui est marqué ‘Private’ dans libraries/mui.h c’est oublié aussi évidement.

Pour finir, je regarde ce ficher avec MUI_OBSOLETE non définis (ce qui vire pas mal de chose aussi).

Ah et j’ai oublié de préciser qq chose d’important: pour l’instant je limite le support à MUI 3.8. On verra plus tard le 4.0. De toute façon cela ne change pas grand chose.

Pour l’instant faire une syntaxe simple pour créer des objets et les utiliser, ça va. C’est la définition des classes existantes et proposer une façon simple d’en définir des nouvelles qui me pose plus de pb.

D’ailleurs dans ces derniers cas, j’ai l’idée qu’on puisse écrire des MCCs en python et que des méthodes comme Setup/Cleanup/Draw/… soient appelables depuis le dispatcher C. Donc écrire une MCC restera quand même d’un niveau bon (savoir écrire une classe en Python par exemple).

Je verrai après l’option d’en écrire en XML ou autre…

[Anonyme]

Anonyme

#87926

Rhalala… c’est typiquement le genre de chose que j’aurais voulu sur Amiga/Pegasos plus tôt !

Mais on ne sait jamais…

En tout cas, une nouvelle fois bravo Guillaume pour tout ce que tu réalises !

Ca devrait permettre un peu plus d’applications « Amiga » natives…

[Yomgui]

Yomgui

#87927

Ah une chose…

Pour ceux qui ont déjà écrit une GUI MUI qui utilise RxMUI ou qui tape dans un port ARexx de leur appli, faut savoir qu’il existe déjà un module ARexx pour Python et qu’il fonctionne.

D’ailleurs à l’Alchimie j’ai montré une petite démo du module MUI qui en qq lignes permet le contrôle de MPlayer par sont interface ARexx.

Le script utilise les modules arexx et mui pour faire l’interface graphique (fenêtre avec 1 ‘slider’) où l’utilisateur pouvait le faire bouger pour se déplacer dans l’anim montrée par MPlayer.

Fab, Henes, BigDan et Batteman peuvent en témoigner: ça marche

[BatteMan]

BatteMan

#87928

Ca marche capitaine, ça marche !!

—

/me se souvient de la pub Airweek ou un truc comme ça.

Only Amiga makes it possible !

[Yomgui]

Yomgui

#87929

Question:

Comme Corto le pointe, j’ai le choix de:

1) garder + ou – la philosophie de MUI, c.-à-d. par exemple notification = appel d’une méthode quand un attribut change.

2) Où bien de généraliser et abstraire MUI (le faire oublier). Et donc aller vers ce qui se fait chez WxWidgets par exemple, gestion d’événements (dont le changements d’attributs en est un cas particulier).

Le deuxième cas étant évidement bien plus souple, puisqu’il permet au programmeur de créer ses propres événements.

Le premier cas facilite le portage bête et méchant.

Qu’en pensez-vous?

Faut que je me décide rapidement… car tout en découle.

Par exemple dans le deuxième cas, MUIM_CallHook n’as plus aucun sens… d’ailleurs toute les méthodes de Notify peuvent êtres ré-écrites dans ce cas de façon plus généraliste (avec une classe ‘Event’ par exemple).