Discussion :

[3DArchi]

Bonjour,
wxWidgets : la bibliothèque C++ pour le développement d'applications multiplateformes, Linux, Window, MAC, fait peau neuve !
En attendant l'évolution majeure que devrait être la version 3.0, wxWidgets a annoncé la sortie de la version 2.9.0 :

We are pleased to announce the first release in the 2.9 development series. wxWidgets 2.9.0 gives a flavour of what will be provided in the stable wxWidgets 3.0 version next year, and we are interested in your feedback. Enhancements in 2.9 include the removal of the distinction between ANSI and Unicode builds, and a reworked Mac OS X architecture, supporting both 32-bit Carbon and 32-bit/64-bit Cocoa variants (wxOSX/Cocoa at alpha stage). You can get wxWidgets 2.9.0 from the download page.

Il ne faut pas se laisser perturber au début par les pages pas forcément mises à jour dans le site de wxWidgets, mais la version est bien sortie et est téléchargeable sur le site sourceForge dédié.
Au menu, la disparition des différentes versions UNICODE/ANSI au profit de la déclinaison UNICODE exclusivement simplifiant ainsi les différents build.
La documentation est maintenant directement générée depuis le code avec Doxygen.
A noter que les boucles d'évènements, les timers et les sockets peuvent maintenant s'utiliser sans I.H.M. Plus toute une flopée de corrections et modifications sur l'ensemble du framework. Le travail est impressionnant.
Avez-vous déjà testé cette nouvelle version ? Vous en pensez quoi ?

[jfouche]

J'ai bien potassé la doc, et je pense l'essayer assez rapidement.
J'aime bien :
- le concept de wxEvtHandler::Bind
- l'arrivée de wxPropGrid inclus dans la bibliotheque
- l'ABI permettant de linker une appli debug avec une bibliotheque wxWidgets release
- wxDataViewCtrl

Par contre, je ne sais pas tres bien l'avantage que je vais tirer du fait que les chaines sont systematiquement en UTF16 sous MSW et UTF8 sous Linux / MAC. Mouais, c'est transparent, et ça n'est pas mon pb...

Bref, ravi en général, et curieux. Je vous proposerai des retours lorsque j'aurai porté mon appli vers 2.9.

[3DArchi]

J'ai bien potassé la doc, et je pense l'essayer assez rapidement.
J'aime bien :
- le concept de wxEvtHandler::Bind
- l'arrivée de wxPropGrid inclus dans la bibliotheque
- l'ABI permettant de linker une appli debug avec une bibliotheque wxWidgets release
- wxDataViewCtrl

Par contre, je ne sais pas tres bien l'avantage que je vais tirer du fait que les chaines sont systematiquement en UTF16 sous MSW et UTF8 sous Linux / MAC. Mouais, c'est transparent, et ça n'est pas mon pb...

Bref, ravi en général, et curieux. Je vous proposerai des retours lorsque j'aurai porté mon appli vers 2.9.

On attend un retour avec impatience.
Il y a eu quand même beaucoup de corrections sur l'ensemble de la bibliothèque. Mais cette version est quand même présentée comme une première étape avant le grand saut vers la 3.0. qui promet d'être révolutionnaire.

[cumu]

Bonjour

J'ai passé un très gros projet professionnel développé durant 2 ans. J'était sous wxWidgets 2.8.10 ANSI.

Je vous cache pas que j'ai eu quelque difficulté à jongler entre le wxString unicode, le std::wstring et le std::string de boost::python. Mais au final ca fonctionne mieux que l'ansi.

J'ai eu également un problème avec wxProgressDialog qui m'a retourné l'erreur "wxProgressDialog::UpdateMessage needs a running event loop ". J'ai résolu le problème en initialisant le projet lors de l'appel à wxApp::OnEventLoopEnter avec certaines conditions pour s'assurer que ce soit lors du bon appel. Et j'ai remarque également qu'il y a une surcharge significative (2 minutes de temps cpu) si vous l'utilisez avec une précision de 10000 ticks (et 10000 UpdateMessage), mais j'ai la flemme de reporter le problème.

Ca a été transparent pour les fichiers de localisation et pour les fichier XML qui étaient déjà en UTF-8.

J'ai bien aimé l'amélioration significative des wxGrid au niveau des redimensionnement automatique des libellés et des rendu des wxGridCellBoolRenderer. J'ai dû faire quelques modif sur mon wxGridCellTreeEditor car les méthodes virtuelles de wxGridCellEditor ont été modifiés.

J'avais des plantages en mode release lors de mon passage en wxwidgets 2.8.10 qui ont disparu avec ce passage à la wxWidgets 2.9

Je crois que c'est tout pour l'instant.

Au final c'est vraiment une mise à jour indispensable, c'est du trés bon travail.

PS: La documentation .chm de wxWidgets est 100x meilleur avec cette nouvelle version. J'était sur le c*l ^^

[3DArchi]

Merci pour ce retour. Je crois en déduire que globalement tu trouves cela plutôt positif. Tant mieux pour wxWidgets !

[Feneck91]

Bonjour, je suis en phase de conception sur un projet professionnel qui va utiliser wxWidgets en compilation UNICODE.
Je pense prendre la dernière version stable sortie et pour le moment hélas, c'est la version 2.8.10 :-/

A noter que les boucles d'évènements, les timers et les sockets peuvent maintenant s'utiliser sans I.H.M. Plus toute une flopée de corrections et modifications sur l'ensemble du framework. Le travail est impressionnant.
Avez-vous déjà testé cette nouvelle version ? Vous en pensez quoi ?

Je suis aussi sur un projet personnel client/serveur avec des sockets, la partie serveur n'a aucune IHM et pourtant elle utilise des sockets en mode asynchrone.... quelle est donc la nouveauté sur les sockets en 2.9 ?
As-tu une idée sur la sortie officielle de la version 2.9 ?

[Muetdhiver]

Feneck,

comme le dit 3D Archi, la version 2.9 est deja sortie depuis quelques mois. Mais elle ne sortira jamais en "stable release" si telle était ta question. Il est important de comprendre le fonctionnement des releases wxwidgets, comme précisé dans la roadmap:

First of all, it is useful to know that wxWidgets has stable release branch and a development branch. The stable branch preserves both API and ABI (binary) compatibility between all releases in the same series while the development branches may (and, while, rarely, sometimes do) break API and don't attempt to preserve the ABI at all.

(http://trac.wxwidgets.org/wiki/Roadmap)

La branche stable est 2.8.x, et dans le futur elle deviendra 3.0 (je crois).
Par contre la 2.9 va évoluer pour rejoindre la 3.0 de façon définitive.

D'après ce que j'ai compris de 3D Archi (je me suis jamais penché sur le sujet, et je n'ai jamais utilisé wxwidgets 2.9 pour le moment), mais la nouveauté sur les sockets porte sur le découpage des libs dans wxwidgets, c'est a dire qu'il n'est plus utile d'inclure le framework graphique pour utiliser les classes de sockets. Je pense qu'en 2.8.10 inclure wxbase (qui contient les TString, les sockets, et tout et tout) contenait également la librairie graphique, ce qui, en effet, n'était pas très judicieux.

Si tu veux développer un serveur avec wxwidgets pour les sockets, mais sans IHM, alors effectivement il te faudra la version 2.9, ou alors tu peux rester avec la 2.8.10 mais tu incluras les libs graphiques pour rien (bien qu'elles soient nécessaires pour linker) et donc tu gonfleras inutilement la taille de ton appli.

En meme temps arrêtez moi si je me trompe, je ne suis pas sur de ce que j'avance !

A+
Alexandre.

PS : pour ma part je prévois un portage de mon appli que je développe depuis 3 ans (environ 30000 loc) (portage de 2.8.10 à 2.9.0 ou 2.9.1 pt etre ?) d'ici environ 3 mois.

Je posterai des retours sur ce portage, ca a l'air super enthousiasmant déjà ces quelques retours !!

[Muetdhiver]

En meme temps je reviens sur ce que j'ai dit car ça me semble étrange aussi cette histoire, les sockets sont contenus dans wxNet, et wxNet ne dépend que de wxBase (qui ne contient pas de GUI). Et en 2.8.10 c'est la meme chose, donc je ne vois pas vraiment pourquoi cette remarque sur les sockets l'IHM.

[3DArchi]

En meme temps je reviens sur ce que j'ai dit car ça me semble étrange aussi cette histoire, les sockets sont contenus dans wxNet, et wxNet ne dépend que de wxBase (qui ne contient pas de GUI). Et en 2.8.10 c'est la meme chose, donc je ne vois pas vraiment pourquoi cette remarque sur les sockets l'IHM.

Salut,
Je n'ai pas creusé le problème mais il me semble qu'avant on avait besoin d'une boucle de message pour les sockets (au moins pour les évènements). D'où la nécessité d'avoir une fenêtre ne serait-ce que cachée. Du moins, c'est comme ça que je l'avais compris. En même temps, comme dit au début, je n'ai pas creusé. C'est donc peut être un à priori erroné. Pour le premier post, je me suis basé sur les infos de release de wxWidgets qui correspondaient à peu près à ce que je pensais être.