Bonjour à tous.
wxWidgets mouture 2.5.4 est disponible depuis peu sur SourceForge.net http://sourceforge.net/projects/wxwindows/(...) .
C'est une version principalement d'éradication des bugs et un peu d'évolution de l'API.
Bien que l'annonce ne soit pas encore éditée sur le site officiel (http://www.wxwidgets.org(...)) une liste partielle des changements est disponibles sur http://wiki.wxwidgets.org/wiki.pl?NextRelease(...) .
Bien sur, pour ceux qui sont fanas du cvs, cette version est téléchargeable sous le tag "WX_2_5_4".
Bien que la branche 2.5.x ne soit pas utilisée par tous les programmes en wx, il est conseillé de commencer à porter les programmes wx2.4.x en wx2.5 car la liste des fonctions marquées "deprecated" s'allonge (il s'agit surtout de reliquats des anciennes versions 2.0 et 2.2 conservée par soucis de compatibilité).
Journal wxWidgets 2.5.4 disponible sur SF
22
fév.
2005
# tkinter
Posté par rangzen (site web personnel) . Évalué à 2.
Je retourne à tkinter pour le basique portable et gtk pour le linux only.
[^] # Re: tkinter
Posté par fredix . Évalué à 3.
pygtk fonctionne également sur Windows :)
[^] # Re: tkinter
Posté par Philippe F (site web personnel) . Évalué à 3.
[^] # Re: tkinter
Posté par Andreas Thillosen . Évalué à 3.
Si l'on veut être sûr de pouvoir tout gérer, il suffit d'installer le support pour tous les modules, ou alors distribuer des binaires liés statiquement.
Néanmoins, c'est à mes yeux une bonne nouvelle de voir un tel projet se développer plus en avant. C'est le meilleur exemple que je connaisse de framework libre multiplateforme qui permette d'employer les widgets natifs de chaque environnement visé.
Ce qui me dérange par exemple dans tk, gtk ou qt (sans pour autant nier leurs qualités respectives), c'est qu'ils s'intègrent mal lorsqu'on tente de faire des applications windows ou OS X.
Et je ne crois pas beaucoup aux bidouilles de thèmes permettant de faire passer du gtk pour du carbon, du qt pour du gtk etc.
Avec wx, on a enfin la chance de faire des applications qui paraissent natives du point de vue de l'utilisateur, quelle que soit la plateforme.
Et en plus de ça, c'est le pied de pouvoir gérer d'autres fonctions telles que le réseau ou les threads, sans pour cela avoir à employer des librairies non portables.
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 2.
wxWidget c'est gentil mais contrairement à ce que tu veux bien faire croire, celà pousse surtout à une chose : un manque d'intégration.
Bah oui mais non car ca utilise un toolkit natif et blablabla.
Quand vous comprendrez que y'a des règles d'ergonomie et des guide d'interfaces qui ne sont pas du tout compatible selon les OS (voir selon les desktop), vous aurez fait un chemin vers l'intégration et le confort de l'utilisateur.
Et à ma connaissance je ne connais aucun toolkit capable de respecter ces règles, tous se contentant d'une intégration "visuelle" plus ou moins réussite. Alors jusqu'à preuve du contraire, la seule et vraie bonne solution lorsque l'on cherche la qualité d'une interface, c'est de faire une bonne architecture indépendante de tout toolkit et de prendre ses 2 doigts et de coder la couche la plus plus proche du toolkit selon les OS visés : bref, utiliser Qt, GTK, les WinForms ou Cocoa.
Evidemment pour les fainéant c'est pas optimisé, mais dans ce domaine bien particulier, c'est incompatible avec la qualité.
[^] # Re: tkinter
Posté par Andreas Thillosen . Évalué à 4.
Je n'ai jamais sous-entendu que wx était la solution ultime à la réalisation d'interfaces ergonomiques. Pour cela, je suis tout à fait d'accord avec toi que rien ne vaudra jamais la programmation directe au sein du toolkit natif.
Néamoins wx a été conçu pour répondre à un besoin, celui de rendre des applications portables, et à moindre coût. Et je trouve qu'il atteint son but de manière très sympatique.
Tout le monde n'a pas forcément les moyens ni le temps de s'approprier toutes les plateformes nécessaires aux différentes variantes d'un même logiciel. Et le fait de coder à l'aide d'un tel framekit permet d'une part de toucher plus d'utilisateurs, mais également de faire collaborer plus de programmeurs.
Et force est de constater que des efforts peuvent être portés envers une meilleure intégration de wx dans chaque OS... par exemple en laissant le soin à wx d'organiser l'ordonnancement des boutons OK, cancel etc. de la manière où cela a été défini pour chaque toolkit visé.
En poussant au maximum ce genre de guidage, on n'arrivera sans doute jamais au même degré de cohérence qu'un toolkit natif, mais je pense (j'ose espérer?) que l'on pourra atteindre une certaine homogénéité au sein de chaque OS.
Et c'est bien la raison pour laquelle je pense que ce genre de projet mérite qu'on porte attention...
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 3.
Bien que l'objectif soit louable, l'utilisation qui est en faite conduit à de gros problèmes d'ergonomie, souvent impossible à résoudre sans changer totalement la conception de l'application.
C'est pourquoi je préfère sensibiliser les programmeurs aux vrais problèmes et bien leur montrer que wx n'est pas une bonne solution en soit lorsque l'on recherche un produit intégré, notamment un produit dit "grand public".
Alors dire que wxWidget a seulement été conçu pour répondre au besoin de portabilité est un peu facile : GTK est tout aussi portable, comme l'est Qt, le principal argument de wxWidget, c'est de proposer à l'utilisateur un truc qui soit-disant s'intègre et non d'offrir une alternative portable avec ses spécificités.
[^] # Re: tkinter
Posté par Émilien Kia (site web personnel) . Évalué à 0.
En effet, tu donnes des arguments opposés :
dire que wxWidget a seulement été conçu pour répondre au besoin de portabilité est un peu facile : GTK est tout aussi portable, comme l'est Qt, le principal argument de wxWidget, c'est de proposer à l'utilisateur un truc qui soit-disant s'intègre et non d'offrir une alternative portable avec ses spécificités.
C'est vrai que gtk est portable mais il implémente son propre look. Tu parlais précédemment d'ergonomie, mais si tu connais assez les lois d'IHM, tu devrais savoir que la cohérence visuelle (intra et inter application) est une loi très importante or utiliser un framekit qui viole complètement le look standard de la plateforme (sous Windows principalement) n'est pas très cohérent au niveau IHM. Hors cette tâche d'intégration est tout à fait accomplie par wxWidgets.
Le fait de ne pas séparer l'interface du noyau fonctionnelle est du ressort du programmeur, pas des développeurs des toolkits (framekits et libs fonctionnelles). Pour mémoire, wxWidgets implémente une couche interface mais fait aussi la part belle au fonctionnel, c'est à l'utilisateur de wx de faire la séparation.
Un jour libre ?
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 1.
Evidemment que c'est du ressort du programmeur de bien architecturer son application, mais lorsqu'un toolkit lui propose tout et n'importe quoi, des objets d'IHM en passant par les threads et la couche réseau, celà va être dûr de concevoir une application indépendante du toolkit en question.
Et comme je l'ai déjà dis, wxWidget a des objectifs louable en soit mais il cache trop souvent un autre problème et finalement ne résoud en rien l'intégration puisqu'il conduit à des logiciels difficilement modifiables.
Donc bref, rien ne vaut une bonne sensibilisation aux vrais problèmes que wxWidgets ne résoud pas pour qu'il soit utilisé en tant que solution "intermédiaire" et no définitive comme on le voit trop souvent.
[^] # Re: tkinter
Posté par Émilien Kia (site web personnel) . Évalué à 1.
C'est un comble. Depuis quand un toolkit qui permet de faire plusieurs chose (framekit mais aussi acces réseau ...) est problématique ?
(L'exemple le plus flagrant est celui du java et de son SDK)
Libre à toi d'utiliser des bibliothèques différentes pour chaque parties de ton application mais si une bibliothèque permet de gérer plusieurs parties d'un soft, de manière portable (msw, unix, mac, wince, et maintenant palm) et libre (c'est quand même le but de wx), c'est quand même une bonne chose.
Et le but n'est pas d'etre indépendant à un toolkit, car tu seras toujours dépendant d'un toolkit à partir du moment où ton soft n'est pas un OS à part entière (et encore) mais d'être indépendant à une plateforme : le but est l'interopérabilité et la portabilité (avec un soucis de cohérence visuelle).
Un jour libre ?
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 1.
Evidemment que le choix d'un langage et de ce qui va avec créé une dépendance, mais il faut bien coder avec quelque chose, le tookit de base faisant souvent parti du langage et peut donc être considéré comme standard et souvent stable.
Créer une dépendance supplémentaire, vis-à-vis d'un toolkit technique en plus, est par contre plus contestable : on ajoute un risque supplémentaire : il est donc vital de rendre indépendant l'application de ce toolkit en créant les abstractions qui vont bien. Quand il s'agit des threads celà commence à devenir pénible, le toolkit venant s'incruster au plus profond de l'application : on risque d'y perdre en temps et en efficacité si on veut s'en abstraire.
Et le but n'est pas d'etre indépendant à un toolkit, car tu seras toujours dépendant d'un toolkit à partir du moment
C'est comme si je te dis : je suis dépendant de la cigarette, bon allez hop on s'en fou, autant être dépendant aussi à l'alcool ou tout autre forme de drogue.
C'est aussi idiot comme raisonnement : dans notre cas précis on a une dépendance évidente liée au fait qu'il faut implémenter l'appli dans un langage, et lorsque celui-ci propose des services de base il faut les utiliser, notamment la notion de thread. Ce n'est pas une raison pour se rajouter 15000 dépendances inutiles, ou tout du moins ce n'est pas une raison pour ne pas y faire attention et de ne pas ajouter de couche d'abstraction.
Là encore je ne dis pas que wxWidget c'est mal, je veux juste attirer votre attention sur les dangers d'utiliser ce genre de toolkit sans faire un minimum attention à la notion de dépendance.
[^] # Re: tkinter
Posté par Erwan . Évalué à 1.
Pour Qt c'est pareil, alors que dans une interview il n'y a pas si longtemps que ca je lisais de la part des developpeurs de wxWindows "Qt recopie pixel par pixel le look de Windows".
Bref, wxWindows c'etait probablement bien a l'epoque ou les concurrents n'etaient pas tres portables mais depuis ils n'ont pas trop evolue et ont, a mon avis, perdu leur avantage.
Ils se retrouvent en 2005 avec un toolkit qui marche bien sous Windows, mais qui se base toujours sur Gtk 1 sous Linux (!!) et les autres ports, en particulier le port Mac, a l'air bien incomplet.
Bref, je me demande toujours quel est l'atout de wxWindows sur Gtk ou Qt... Mais c'est peut-etre par ignorance.
[^] # Re: tkinter
Posté par Victor . Évalué à 3.
Et precedemment, gtk2 etait present sur la 2.4 (bien que a peu pres pas du tout utilisable).
[^] # Re: tkinter
Posté par Andreas Thillosen . Évalué à 1.
Quant à Gtk sous windows, certes par un truchement de thème, Gaim et Gimp parviennent à ressembler à Windows... néamoins, en cas de changement du thème de base de ce dernier, on finit par tomber sur une incohérence visuelle.
Avec wx, on ne peut avoir ce genre de problème vu que les widgets natifs de l'OS sont exploités.
De plus, il faut reconnaître qu'une application liée à Gtk sous windows montre une certaine lourdeur à démarrer, car c'est toute la machinerie Gdk/Gtk qui se lance par-derrière (il suffit de voir l'activité disque lors du lancement de Gaim pour s'en rendre compte).
En revanche, les applications telles qu'audacity ou mes propres programmes, en général liés statiquement, se montrent tout aussi dynamiques que les programmes windows natifs.
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 2.
Non non, tu changes de thème Windows, ben l'appli GTK aussi. Il suffit d'utiliser le thème très répendu et souvent utilisé par défaut, GTK-Wimp. Comme indiqué sur leur site :
'When running on XP, the Windows theming API is used so that GTK widgets look like native widgets.'
Quand à la loudeur du chargement, je ne l'ai jamais rencontré, il suffit par exemple de lancer Gaim pour s'en rendre compte. La machinerie Gtk est une couche entre l'OS et l'appli au même titre que la machinerie wxWidgets, qui a elle aussi besoin d'être chargé.
De plus quand je vois la tronche du widget arborescence sous Windows, même sous Linux, je me dis que wxWidgets ne doit pas utiliser tout le temps les widgets natifs, et là même GTK s'en sort mieux question intégration :)
[^] # Re: tkinter
Posté par Émilien Kia (site web personnel) . Évalué à 1.
Justement, wxWidgets n'a pas de machinerie puisque c'est un wrapping. Y-a pas de service à démarrer ou de serveur de thème ou tout autre chose de ce genre.
Un jour libre ?
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . Évalué à 2.
Et puis dans la pratique comme je t'ai dis, dans la pratique le chargement d'une appli GTK ne se remarque pas. Bref, c'est pas du tout pertinent comme argument.
[^] # Re: tkinter
Posté par xavier . Évalué à 1.
que de se plier a des normes fourre tout, pour peu que le viol ne soit pas lui meme dicté par les toolkit :)
[^] # Re: tkinter
Posté par SaintGermain . Évalué à 2.
Cela m'intéresse car je m'inquiète en ce moment de la maintenance d'une IHM développée en wxPython.
En particulier si les API des widgets de base changent tous les 4 matins, ça ne va pas être rigolo du tout du tout...
D'un autre côté si ce sont seulement les fonctionnalités très sophistiquées qui sont touchées lors des évolutions, cela me dérangera moins (et en tout cas sera plus justifié...).
D'ailleurs si quelqu'un avait une critique objective de Tcl/Tk ça m'arrangerait, on ne trouve pas trop de comparatif avec la concurrence...
Merci !
[^] # Re: tkinter
Posté par Émilien Kia (site web personnel) . Évalué à 2.
Faut pas abuser non plus. Si l'API a des changements mineurs tous les ans ou tous les deux ans (qui en plus sont annoncés relativement en avance), je trouve pas que ca soit choquant. Toutes les bibliothèques évoluent et je ne trouve pas que wx abuse au niveau des changements. En plus, les fonctions dépréciées sont conservées un bout de temps avant erradication. Et la plupart du temps, il s'agit de rendre l'API plus propre et plus efficace (déplacement de fonctions ...) C'est bien la première fois que je vois un troll sur le fait qu'une bibliothèque cherche à être plus propre et plus efficace.
Effectivement, les puristes vont activer le mode "sans dépréciation" donc très strict au niveau de l'API mais cette fonction est désactivée par défaut. En plus la majorité des fonctions dépréciées sont annoncé depuis plus de deux ans donc ceux qui critiques ces aspects sont un peu de mauvaises fois. Un exemple criant : l'API actuelle des containeurs (list/map/array) est basé depuis plus très longtemps sur des jeux de macros (je connais wx depuis plus de cinq ans et je l'ai toujours connu comme ca) pour pouvoir être compatible avec les vieux compilos. Ils commencent seulement à mettre en place une version basé sur des templates; c'est quand même pas du changement d'architecture à outrance.
Pour le tcl/tk, j'ai connu ca un peu à la fac. La seul chose que je peux dire c'est que niveau syntaxe, je trouve pas ça très propre (comportement différent si tu place un espace entre deux parenthèses ou non ...) et un peu lent vis-à-vis des langages compilés et même de beaucoup de langage (semi-)interprétés. Après ya des amateurs. Je dirais que c'est un peu un non-sens de partir du python pour aller sur TCL/Tk. La logique (toujours à mon sens) serai plutôt de partir d'une interface en tcl/tk pour commencer (pour aller vite et encore) puis de migrer progressivement vers d'autres langages. Mais je ne suis surement pas le mieu placé et surtout le plus objectif.
Un jour libre ?
[^] # Re: tkinter
Posté par rangzen (site web personnel) . Évalué à 4.
Pour les problemes, c'est principalement le passage 2.4 -> 2.5, selon les plateformes le 2.5 a été intégré ou non, certains outils n'utilise pas encore le 2.5 à cause de la récriture. Ca se met à jour doucement.
Chaque plateforme pourrait installer le 2.5 : oui.
Est ce que je suis prés à me taper la compil du 2.5 sur chaque machine différente : non.
Sinon un truc toujours pas résolu par wxpython, la gestion des signaux appli externe vers appli en wxpython, les signaux sont "en attente".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.