C'est vrai quavec pyQT on peut s'affranchir du preprocesseur et c'est appréciable. Mais Fox permet de s'en affranchir même en C++
J'avais essayé de coder un petit proto, il y a quelque temps avec un IHM en PyQT. Franchement y'a plein de petites subtilités agacantes qui laissent un arrière gout d'inachevé aux pythoniens.
Par exemple la gestion des QString:
Toutes les methodes sur les Widgets qui acceptent des chaines comme paramètres convertissent automatiquement les string pyhton en Qstring mais la réciproque n'est pas vraie. Elles renvoient des Qstring qu'il faut convertir explicitement. On t'objectera que c'est pour ne pas penaliser les perf car il s'agit de mutable, que tu evites 2 conversions inutiles quand tu la repasse à un QWidget , ... mais dans la plupart des cas ce n'est pas critique. FxPY reste cohérent, on a jamais affaire à des FXString.
Autre exemple , j'avais besoin de modifier le comportement par défaut d'un Widget (complétion personnalisée). Je n'ai pas trouvé de solution autre que de sous-classer en C++. Ajouter à ca la licence de l'époque, j'ai jeté l'éponge, ca ne ressemblait plus à du RAD.
Certes j'aurais peut être eu le même pb ave Fox .
J'avoue que je suis encore à la quête du St Graal pour développer un IHM full python digne de ce nom avec un framework qui ne souffre pas trop des limitations du langage d'implémentation : utlser Mono, SWT, ObjC, OOo, Mozilla, Wax ...? Ca mériterait sûrement un post sur le forum Python DLFP
A propos
Qu'en est il de PyQT, vont ils s'aligner sur Trolltech et passer en double licence ? Parce que pour les devs python, ca a son importance.
[^] # Re: et wxWidgets dans tout ça ?
Posté par golum . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 0.
J'avais essayé de coder un petit proto, il y a quelque temps avec un IHM en PyQT. Franchement y'a plein de petites subtilités agacantes qui laissent un arrière gout d'inachevé aux pythoniens.
Par exemple la gestion des QString:
Toutes les methodes sur les Widgets qui acceptent des chaines comme paramètres convertissent automatiquement les string pyhton en Qstring mais la réciproque n'est pas vraie. Elles renvoient des Qstring qu'il faut convertir explicitement. On t'objectera que c'est pour ne pas penaliser les perf car il s'agit de mutable, que tu evites 2 conversions inutiles quand tu la repasse à un QWidget , ... mais dans la plupart des cas ce n'est pas critique. FxPY reste cohérent, on a jamais affaire à des FXString.
Autre exemple , j'avais besoin de modifier le comportement par défaut d'un Widget (complétion personnalisée). Je n'ai pas trouvé de solution autre que de sous-classer en C++. Ajouter à ca la licence de l'époque, j'ai jeté l'éponge, ca ne ressemblait plus à du RAD.
Certes j'aurais peut être eu le même pb ave Fox .
J'avoue que je suis encore à la quête du St Graal pour développer un IHM full python digne de ce nom avec un framework qui ne souffre pas trop des limitations du langage d'implémentation : utlser Mono, SWT, ObjC, OOo, Mozilla, Wax ...? Ca mériterait sûrement un post sur le forum Python DLFP
A propos
Qu'en est il de PyQT, vont ils s'aligner sur Trolltech et passer en double licence ? Parce que pour les devs python, ca a son importance.