wxWidgets 3.0

Posté par  (site web personnel, Mastodon) . Édité par Davy Defaud, Benoît Sibaud, fravashyo, palm123 et claudex. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes : aucune
38
12
nov.
2013
Technologie

Après des années de développement, et une phase RC entamée début octobre, la nouvelle version stable de la bibliothèque graphique libre wxWidgets est désormais disponible. Il faut dire que wxWidgets 2.8.x est présente depuis décembre 2006, et nous en sommes actuellement à la version 2.8.12 datant de mars 2011 ! Cette nouvelle version apporte une certaine fraîcheur à cette bibliothèque plus que stable.

logo wxwidget

Parmi les nouveautés, on peut retenir notamment :

  • une prise en charge de l’Unicode bien meilleure, transparente et simplifiée ;
  • un nouveau portage pour OSX / Cocoa (via wxOSX), permettant le développement d’interfaces applicatives en 64 bits sous OS X ;
  • la prise en compte de GTK+ 3 dans wxGTK ;
  • une nouvelle bibliothèque wxRibbon pour réaliser des interfaces sous forme de ruban;
  • une nouvelle interface d’édition de propriétés, wxPropertyGrid ;
  • l’ajout de contrôles graphiques persistants qui sauvegardent et restaurent leur état automatiquement ;
  • la documentation, qui passe du LaTeX à [Doxygen], incluant des captures d’écran des contrôles. Suite à ce changement, l’équipe est friande de vos retours, surtout que la syntaxe est, a priori, plus simple et la soumission de patches aussi.

Consultez le journal des modifications complet, si vous voulez plus de détails sur les nouveautés et surtout les changements. En effet, cette nouvelle version majeure apporte son lot d’incompatibilités, surtout dues au passage à l’Unicode. Une synthèse des changements incompatibles avec la version 2.8 est disponible. Mais, encore une fois, il est préférable d’aller dans le détail si vous êtes développeur.

Rappels sur wxWidget

Anciennement appelée wxWindows, wxWidget est une bibliothèque libre de widgets permettant de créer des interfaces graphiques multi‐plates‐formes, mimant le plus possible l’environnement natif de l’utilisateur. Le nombre de logiciels l’utilisant est impressionnant ; parmi les plus connus, on peut citer 0 A.D. (jeu type Age of Empires), Amaya (navigateur et éditeur Web), Audacity, BitTorrent, Code::Blocks, FileZilla, TortoiseCVS, etc. Le nombre de plates‐formes prises en charge est tout aussi impressionnant :

  • Microsoft Windows, via wxMSW, incluant Windows 95, 98, Me, NT, 2000, XP, Vista, 7 et 8 ;
  • GNU/Linux et Unix via wxGTK, wxX11 et wxMotif ;
  • OS X via wxMac (10.3 via Carbon) ;
  • OS/2 via wxOS2 ;
  • l’embarqué avec wxEmbedded (Windows CE, PalmOS, etc.).

capture d'écran de Caedium utilisant wxWidget

Il est écrit en C++, mais parmi les bindings proposés, il y a certainement un langage de programmation que vous connaissez :

  • Python
  • Perl
  • BASIC
  • Lua
  • OCaml
  • JavaScript
  • Java
  • Ruby
  • Eiffel
  • Haskell
  • C#/.NET
  • Euphoria
  • D

Feuille de route

Pour la prochaine version, le projet prévoit une grosse réécriture de wxAUI (Advanced User Interface), la bibliothèque permettant de créer des [interfaces utilisateur très riches et « dockables », type Eclipse.

capture d'écran wxAUI

La version 3.2 sera aussi l’occasion d’abandonner tout support pour les vieilleries qui traînent dans le placard et qui ne sont même plus supportées par leur éditeur, notamment pour la série des Windows 9x, ainsi que les compilateurs MSVC6, voire 7. Enfin, parmi les souhaits de l’équipe :

  • finir l’implémentation de wxMaskedEdit ;
  • la traduction dépendante du contexte dans wxLocale ;
  • l’implémentation de colonnes et lignes figées dans le composant wxGrid ;
  • améliorer les boîtes de dialogue modales.

Aller plus loin

  • # Et python 3 ?

    Posté par  (site web personnel) . Évalué à 10.

    Un gros problème indirect de WxWidget, c'est le fait que WxPython ne fonctionne qu'en Python 2. Ca commence à être génant pour certains projets.

    Plutôt que de porter le code actuel, ce qui est prévu est une réécriture complète du générateur de binding Python, pour supporter à la fois Python 2 et Python 3, avec une syntaxe légèrement différent. Ca a pris le nom de "Projet Phoenix": http://wxpython.org/Phoenix/docs/html/

    Comme tous les gros projets de réécriture, il tarde à se matérialiser…

    Philippe

  • # je n'ai jamais utilisé wxWidgets

    Posté par  . Évalué à 3.

    mimant le plus possible l'environnement natif de l'utilisateur.

    Une interface wxWidgets adapte-elle juste l'affichage (couleurs, formes) ou aussi les interactions (ie, user experience) ?

    [troll] Si c'est juste l'affichage qui est adapté, quels avantages par rapport à Qt ? [/troll]

    • [^] # Re: je n'ai jamais utilisé wxWidgets

      Posté par  . Évalué à 2.

      [troll] Si c'est juste l'affichage qui est adapté, quels avantages par rapport à Qt ? [/troll]

      Le nombre de binding pour différent langages?

      • [^] # Re: je n'ai jamais utilisé wxWidgets

        Posté par  (site web personnel) . Évalué à 10.

        Il y a vraiment deux approches différentes entre WxWidget et Qt.

        Qt émule le look'n feel des contrôles des différentes environnements. Donc un ComboBox Qt par exemple, est avant-tout un combo-box écrit par Qt en C++, et un certain nombre de ses comportements sont adaptés selon la plate-forme.

        WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible. Donc en théorie, en combo-box en WxWidget sous Windows, c'est un combo-box de Windows, sous MacOs, c'est l'OS qui fourni le combo-box, etc etc.

        Dans la théorie, ça crée une émulation plus fidèle des contrôles de la plate-forme, mais au risque de d'introduire des bugs qui sont spécifiques à la plate-forme à cause de comportements légèrement différents d'une plate-forme à l'autre. Un autre inconvénient, c'est qu'on se retrouve vite à faire du nivellement par le bas: telle plate-forme ne fournit pas un contrôle donné, donc soit Wx ne le fournit pas, soit Wx doit l'émuler et prend la même démarche que Qt, faire un codage interne. J'ai vu traîner dans la documentation ce genre de cas mais j'ai plus d'exemples en tête.

        Au final, il me semble que WxWidget fournit pas mal de Widget maison (approche à la Qt) et des widgets natifs uniquement pour les contrôles de base. Et surtout, sur un certains nombre de plate-forme, c'est plus vraiment les widgets natifs qui sont utilisés. Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.

        En tout cas, en Python, c'est un des GUI les plus populaires (loin devant PyQt il me semble).

        • [^] # Re: je n'ai jamais utilisé wxWidgets

          Posté par  (site web personnel) . Évalué à 5.

          Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.

          Non c'est bien Cocoa qui est utilisé

        • [^] # Re: je n'ai jamais utilisé wxWidgets

          Posté par  . Évalué à 8.

          WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible.

          Enfin bon, WxWidget sous KDE ça fait pas très «natif». Je suppose que c’est parce que c’est basé sur GTK sous GNU/Linux, non?

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: je n'ai jamais utilisé wxWidgets

          Posté par  . Évalué à 8. Dernière modification le 13 novembre 2013 à 07:03.

          L'utilisation de Wxwidgets se fait generalement de la façon suivante:

          Je ne dois faire qu'une gui. St s'est lourd et complique, gtk c'est pas vraiment multiplateforme, tk c'est moche et basique. Bon je vais tenter wxwidgets, c'est pas mal et la la cata arrive: wxwidget sort une nouvelle version (non majeure) et tout est cassé, tu portes ( en talant ). La 2ee fois que cela arrive, tu portes sur Qt et tu te maudis d'avoir fait le mauvais choix auparavant car tu t'aperçois que ca marche, que c'est simple, que tu n'as besoin que de Qtgui…

          En gros wxwidget c'est amusant mais pas trop longtemps.

    • [^] # Re: je n'ai jamais utilisé wxWidgets

      Posté par  . Évalué à 2.

      L'UX varie énormément d'une plateforme à l'autre (Mac OS X, Windows, Windows 8, KDE, GNOME, etc.). Le système de widgets le plus futé du monde n'y pourra rien. L'application aura toujours l'air de venir "d'ailleurs" et s'intégrera mal.

      BeOS le faisait il y a 20 ans !

      • [^] # Re: je n'ai jamais utilisé wxWidgets

        Posté par  (site web personnel) . Évalué à 2.

        On peut aussi factoriser les concepts communs et proposer des composants spécifiques à certaines plateformes.
        C'est le choix de Qt.
        Par exemple, le QSystemTrayIcon ne fonctionne pas sur certaines versions de MacOS.

        Ca demande pour l'utilisateur du toolkit de coder de façon conditionnelle en fonction des plateformes cibles, mais on bénéficie au moins de la standardisation de l'API haut niveau et de son soucis de factorisation des concepts.
        Après, si c'est pas parfait, c'est parce que faire un tel toolkit qui irait gérer tous les concepts de toutes les plateformes "jusqu'au bout des ongles" nécessiterait une puissance de feu incroyable, mais c'est au moins théoriquement faisable.

        • [^] # Re: je n'ai jamais utilisé wxWidgets

          Posté par  (site web personnel) . Évalué à 10.

          J'ai longtemps pensé que l'approche à la WxWidget était la bonne, car le portage vers une nouvelle plate-forme voulait uniquement dire de faire rentrer les contrôles existants dans l'api de WxWidget. Toute la partie look devenait natif et suivait la plate-forme (ce qui faisait taire les râleurs).

          A l'inverse Qt, pour un nouveau portage, doit redévelopper un système d'affichage bas-niveau. Et quand il y a des nouveaux moteurs de look (Win98 -> XP -> Vista -> Seven), il faut redévelopper le moteur de thème pour tirer partie des derniers moteurs. C'est un problème en particuliers quand une plate-forme non majeur sort un nouveau moteur, il se peut que les développeurs de Qt ne soient pas rapides à l'intégrer et on voit alors des trolls surgir sur Linuxfr.

          J'ai cependant complètement changé d'avis avec le temps et à l'utilisation de Qt. Au fur à mesure que Qt a pris en maturité, les contrôles/widgets sont devenus de plus en plus élaborés, bien plus que ceux qu'on trouve en natif sur la plate-forme, battant en brèche un des avantages de WxWidget.

          De plus en terme de debug, les widgets de Qt sont débuggés une fois pour toute, le code étant commun à plusieurs plate-formes, alors qu'il est régulier que Wx se traîne des bugs spécifiques à des plate-formes. Et je ne peux pas les blâmer pour ça, qui peut garantir que par exemple les ascenseurs Windows, MacOs et Gtk soient complètement "unifiables" en terme d’événements envoyés à la pile graphique.

          Au final, la stratégie de Qt paye sur le long terme. Au fur à mesure que le nombre de plate-forme augmente, et le nombre de widget aussi, l'effort de développement côté Qt reste relativement linéaire avec une pente assez douce, car dès que le moteur graphique est porté, tous les widgets suivent instantanément. De même, pour un nouveau look'n feel, Qt a maintenant un moteur de style suffisamment costaud pour absorber beaucoup des dernières nouveautés.

          Pour Wx, chaque nouvelle plate-forme multiple de façon exponentiel le travail de maintenance et d'évolution, car il faut gérer des nouveaux comportements des widgets natifs.

          En tout cas, on constate que :

          • Wx utilise l'approche Qt pour un certain nombre de Widget avancés, qui ne sont pas communs à toutes les plate-formes et doivent être fait en natif.
          • Qt utilise l'approche de Wx pour un très petit nombre de briques, où le choix est proposé entre la version par défaut de Qt ou la version native: dialgue de fichier, system tray, et je sais plus quoi d'autre.

          Tout le monde peut donc se faire des bisous, tout va bien.

          • [^] # Re: je n'ai jamais utilisé wxWidgets

            Posté par  . Évalué à 4.

            • Wx utilise l'approche Qt pour un certain nombre de Widget avancés, qui ne sont pas communs à toutes les plate-formes et doivent être fait en natif.
            • Qt utilise l'approche de Wx pour un très petit nombre de briques, où le choix est proposé entre la version par défaut de Qt ou la version native: dialgue de fichier, system tray, et je sais plus quoi d'autre.

            C'est un réel atout d'avoir le choix avec Qt.
            Exemple tout neuf sous Mac : les boites de sélection de fichiers natives fonctionnent mal depuis le passage à OSX 10.9 (perte du répertoire en cas de présélection de fichier). Pas de soucis, il suffit de basculer aux boites made in Qt qui ont un comportement parfaitement prévisible. Le look est différent, soit, mais en quelques copier-coller on peut générer et distribuer une release qui marche (sur ses 2 jambes), en attendant que le bug soit fixé.

  • # Bonne bilbliothèque mais...

    Posté par  . Évalué à 6.

    Bonsoir,
    j'ai utilisé wxWidgets pendant des années et j'ai essayé Qt avec le changement de licence. Et honnêtement il n'y a pas photo. Le développement est plus propre, plus rapide et tout marche. Alors que sous wxWidgets il y avait des manques (sur le réseau…), quelques bugs aussi et des problèmes lorsque l'on voulait faire des choses qui sortent de l'ordinaire.
    Bonne bibliothèque sinon mais le couple Qt+QtCreator est bien supérieur (essayer wxFormbuilder pour faire des IHM sinon).
    Bonne soirée

    • [^] # Re: Bonne bilbliothèque mais...

      Posté par  . Évalué à 1.

      j'ai utilisé wxWidgets pendant des années et j'ai essayé Qt avec le changement de licence. Et honnêtement il n'y a pas photo.

      Hum, encore faut-il qu'il y ai un bon binding pour Qt dans le langage que tu veux utilisé!
      Coté binding Qt ce n'est pas la joix: binding D pas très maintenu, binding Nimrod inexistant..

  • # Et erlang ?

    Posté par  (site web personnel) . Évalué à 3.

    A noter également le binding erlang qui fait partie d'OTP (la plate-forme standard) et qui remplace le vénérable tk:
    http://www.erlang.org/doc/apps/wx/chapter.html

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.