Pour rappel, wxWidgets est une bibliothèque graphique portable "native" pour GTK (NdM : 1.2.x, mais aussi 2.x avec cette nouvelle version), Motif, X11, OS/2, Mac OS 9, Mac OS X, Win16, Win32, WinCE, Nano-X, MGL et Palm OS.
Dans cette nouvelle version majeure, un important travail sur le support de la STL a été fait. De nouvelles fonctionnalités ont fait leur apparition comme, par exemple, wxGridBagSizer qui permet de décrire l'organisation d'une fenêtre comme un tableau dont les cases peuvent fusionner. Espérons que cette nouvelle version permette à encore plus de développeurs de découvrir ce fabuleux framework très bien documenté. Bien plus qu'un dénominateur commun de tous les environnements graphiques, elle se "link" avec la bibliothèque graphique de la plate-forme et prend donc l'apparence de celle-ci. Il est également possible d'utiliser les spécificités de la plate-forme (au dépend de la portabilité).
En réalité, wxWidgets est un framework complet : des fonctionnalités telles que les threads, le réseau, l'affichage HTML et bien d'autres y sont présentes.
Il est écrit en C++ mais est également très utilisé en Python. De nombreux autres langages tels que Perl, Haskell, Basic ou Ruby sont supportés dans un état plus ou moins avancé.
Enfin, cerise sur le gâteau, le tout est distribué sous une licence basée sur LGPL avec une exception permettant aux logiciels commerciaux de ne pas fournir leurs sources.
--------------------------
Le traditionnel "Hello world" :
#include "wx/wx.h"
class MyFrame: public wxFrame
{
public:
MyFrame(const wxString& title)
: wxFrame((wxFrame *)NULL, -1, title)
{
wxMenu *menuFile = new wxMenu;
menuFile->Append(wxID_EXIT, "E&xit");
wxMenuBar *menuBar = new wxMenuBar;
menuBar->Append(menuFile, "&File");
this->SetMenuBar(menuBar);
}
void OnQuit(wxCommandEvent& event)
{
this->Close(true);
}
DECLARE_EVENT_TABLE()
};
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(wxID_EXIT, MyFrame::OnQuit)
END_EVENT_TABLE()
class MyApp: public wxApp
{
virtual bool OnInit()
{
MyFrame *frame = new MyFrame( "Hello World");
frame->Show(true);
this->SetTopWindow(frame);
return true;
}
};
IMPLEMENT_APP(MyApp)
Aller plus loin
- Le site de WxWidgets (14 clics)
- Le changement de nom (2 clics)
- Les plateformes supportées (2 clics)
# drôle de cerise sur un drôle de gateau
Posté par Gniarf . Évalué à 7.
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Olivier jolly . Évalué à 4.
C'est compris dans le "prix" si je ne m'abuse.
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par fleny68 . Évalué à 2.
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Troy McClure (site web personnel) . Évalué à 1.
( http://www.wxwidgets.org/newlicen.htm(...) )
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Frédéric Lopez . Évalué à 2.
Extrait de http://www.wxwidgets.org/newlicen.htm(...) :
« The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software.»
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Erwann Robin (site web personnel) . Évalué à 0.
qui dit exactement la meme chose que la GPL excepté le fait de pouvoi l'inclure dans un prog commercial ?
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Olivier jolly . Évalué à 0.
On peut inclure du code LGPL dans un programme qui a un but différent du code LGPL utilisé. Mais là, il semble qu'on puisse écrire un programme (ou plutot un framework) qui a le même but que wxWidgets, qui réutilise son code, mais qui est couvert par la licence de son choix (de GPL à closed source).
[^] # Re: drôle de cerise sur un drôle de gateau
Posté par Frédéric Lopez . Évalué à 4.
La licence LGPL modifiée utilisée par wxWidgets permet de ne pas avoir à fournir les sources de wxWidgets avec ton binaire, de ne pas avoir à fournir les sources de tes modifications sous LGPL et de pouvoir lier statiquement sans restriction.
# Je me marre
Posté par Philippe F (site web personnel) . Évalué à 1.
Si j'ai bien compris, c'est ce qui permet de faire facilement des fenetres redimensionnables. Impressionnant, c'etait une fonctionnalite de base dans Qt 1.0 (les qlayout) et dans Gtk 1.0 aussi (gtk_pack il me semble).
J'ai du mal a imaginer qu'on puisse sortir un toolkit graphique au 3 millenaire sans ce type de fonctionnalite !
C'est bien, on progresse ! Plus que 10 ans a wxWidget pour rattrapper le retard sur les autres toolkits.
ok, je sors ----> []
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 10.
La programmation par evenement est beaucoup moins souple que les signaux/slot facon Qt, car un evenement ne peut contenir que tres peu d'information: "il se passe qqch". Du coup, pour transporter des informations complexes, on est obliger de rajouter du code qui va chercher l'information la ou elle est. Les exemples simples comme le hello world ne mettent pas en evidence ce probleme, mais quand on rentre dans des cas reels, le flux de communication de donnees a l'interieur de l'application devient complexe. Avec une programmation purement evenementielle comme wxWidgets (ou MFC), ce flux est penible a gerer.
La communication par signaux permet de completement separer la preparation des donnees de leur traitement, et d'offrir plus d'independance entre les differents objets d'une application. Pour ceux qui sont familiers avec les Design Pattern, c'est un probleme recurrent resolu par le Mediateur. Pour faire communiquer un objet A avec un objet B, soit B doit connaitre A, soit A doit connaitre B, soit il y a un objet C entre A et B qui connait A et B. On peut dans ce cas faire evoluer A separement de B a condition de faire suivre C, qui devient le mediateur.
Ce qui est fort avec Qt, c'est que pour les cas simples, le mediateur, c'est la connection signal/slot et qu'il n'y a donc pas besoin de pondre une classe pour ca.
Je donne un exemple simpliste mais concret: une interface graphique doit generer des rectangles dont l'utiisateur controle la hauteur et la largeur. Il entre deux nombres de facon diverses, clique sur un bouton et un rectangle doit etre genere.
Cote interface, il y a donc du code qui doit lire deux nombre. On imagine deux spinbox et un bouton pour generer le tout. De l'autre cote, il y a une partie du programme qui recoit le "signal" de generer un nouveau rectangle.
En Qt, ca donnerait qqch dans le style:
class MyRectangleInput : public QVBox {
Q_OBJECT
public:
MyRectangleInput( QWidget * parent ) {
spin1 = new QSpinBox( this );
spin2 = new QSpinBox( this );
QPushButton * button = new QPushButton("Generate Rectangle");
connect( button, SIGNAL(clicked), this, SLOT(slotGenerate) );
}
slots:
void slotGenerate() {
emit generateRectangle( spin1->value(), spin2->value() );
}
signals:
void generateRectangle( int width, int height );
protected:
QSpinBox *spin1, *spin2;
};
De l'autre cote, on a la classe reception :
class RectangleGenerator : public QWidget
{
// [...]
public slots:
slotGenerateRectangle( int width, int height ) {
// create new rectangle
}
};
Pour faire marcher le tout, il doit y avoir un moment donne une connection entre une instance de MyRectangleInput et RectangleGenerator:
connect( myRectangleInstance, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstance, SLOT(slotGenerateRectangle(int,int)) );
On voit bien que les deux classes sont completement independantes, et ce qui les lie, c'est la connection signal / slot.
[ A noter que le MyRectangleInput peut etre librement redimensionner et que les widget adapteront la bonne taille ]
Si on revient a un toolkit base sur des evenements, on aurait une problematique differente. Je ne connais pas bien wxWidget, mais en reprenant le concept general de la haut, la classe A, c'est le MyRectangleInput, et la classe B, c'est le RectangleGenerator. Dans le cas ou on appuie sur le bouton, un evenment GENERATE_RECTANGLE est envoye. De la, il y a le choix:
- B connait A : la classe RectangleGenerator dispose d'un pointeur vers la classe MyRectangleInput et va lire elle-meme le contenu des spinbox. Le probleme, c'est que si on remplace les spinbox par autre chose, il faut faire evoluer aussi la classe RectangleGenerator. Un autre probleme qui est beauoup plus contraignant, c'est que RectangleGenerator doit disposer d'un pointeur sur MyRectangleInput. Que se passe-t-il si il y a plusieurs MyRectangleInput ? Il faut gerer la vie du pointeur. Que se passe-t-il si une autre partie de l'application veut effacer un pointeur sur MyRectangleInput ? Elle doit en informer toutes les classes qui possedent un pointeur sur MyRectangleInput. Plutot lourd.
- A connait B : cette fois, c'est MyRectangleInput qui connait bien RectangleGenerator, qui appelle directement l'instance avec les bons parametres qu'il va chercher en interne. On peut donc faire evoluer MyRectangleInput facilement. Mais on retombe vite dans une problematique similaire : imaginons qu'on aie plusieurs destinataires du message GENERATE_RECTANGLE. Ils doivent tous s'enregistrer aupres de MyRectangleInput et tous avoir une interface commune. Si en plus on a plusieurs generateurs, on arrive vite a une situation ou il y a n generateurs, n recepteurs et on doit maintenir n x n liens tout en sachant a tout moment que faire si des pointeurs sont effaces.
- C connait A et B : c'est pour ca qu'on a besoin d'une classe supplementaire C. Elle va recevoir l'evenement GENERATE_RECTANGLE, aller cherche l'info dans A parce qu'elle connait bien l'implementation de A, puis dispatcher cette information dans B. Si il y a plusieurs RectangleGenerator et plusieurs MyRectangleInput, la class C maintient la liste des associations et est la seule classe qui doit etre au courant quand un nouveau pointeur est cree ou supprime.
L'avantage dans le modele signaux/slot, c'est qu'on a pas besoin de classe C. Elle est deja dans le toolkit. Dans les problematiques que j'ai cite, on peut imaginer en QT :
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
si on efface un pointeur myRectangleInstanceX, il n'y a rien de special a faire, la connection disparait toute seule. Idem si on efface un rectangleGeneratorX.
Ce probleme peut paraitre simpliste, mais dans une application graphique (et meme non graphique), on a beaucoup de morceaux d'applications a faire communiquer ensemble (typiquement, le frontend et le backend) et les facilites fournies par Qt permettent de gerer cela avec beaucoup de legerete et d'elegance.
Avec une programmation par evenement, le code devient vite abominable et on est tout de suite obliger de faire appel a moultes Design Pattern pour garder un truc maintenable.
[^] # Re: Je me marre
Posté par Frédéric Lopez . Évalué à 5.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 2.
Est-ce que ca se fait dans la pratique ? J'imagine quand meme que les mecs qui font du wxWidgets sont intoxices de notions evenementielles et ont du mal a voir l'interet des signaux / slots.
[^] # Re: Je me marre
Posté par Frédéric Lopez . Évalué à 2.
[^] # Re: Je me marre
Posté par Antoine . Évalué à 3.
[^] # Re: Je me marre
Posté par Christophe Renard . Évalué à 6.
Dans ce but, beaucoup de fonctionnalités de C++ avancé sont mise en standby/ignorées en l'attente de l'uniformisation des compilos.
Gérer des signaux sans utiliser des templates évolués (façon gtkmm) ou un précompilateur (façon QT) ca relève de la gageur.
En revanche il existe des efforts comme litWindow http://www.litwindow.com pour utiliser un style de C++ moderne(en surcouche de wxWidgets) pour la programmation d'interfaces graphiques.
Pour ma part j'utilise souvent les fonctionnalités de Boost et de la lib standard C++ avec Wx pour les fonctionnalités qui semblent plus élégantes et ca marche trés bien (même si les différences de style de notation entre la lib standard/Boost et Wx (héritée des MFC) sont inélégantes).
Bref c'est une librairie qui ne cherche sans doute pas le premier prix d'élégance, mais c'est un outil de plus.
Le choix c'est bon, non ?
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 3.
Dans la mesure ou wxWidget ne se gene pas pour utiliser des macros pour ses evenments, je trouve l'argument un peu faible.
> Il faut sans doute rappeller que wxWidgets à été développé avec l'idée de la portabilité de plateformes mais aussi de compilateurs.
Qt aussi. Et ils ont tres bien reussi.
Ce que je retiens, c'est qu'on peut utiliser des outils exterieurs pour rendre le style de programmation un peu plus moderne mais que ca reste un melange de deux styles, pas toujours tres agreable a manipuler.
Ca plus les problemes specifiques plateformes, ca fait quand meme un bagage assez charge pour un toolkit "moderne".
Je continue a preferer Qt ou tout est super bien integre et on a pas l'impression de remonter dans le temps quand on developpe.
[^] # Re: Je me marre
Posté par Christophe Renard . Évalué à 2.
>>(façon gtkmm) ou un précompilateur (façon QT) ca relève de la gageur.
>Dans la mesure ou wxWidget ne se gene pas pour utiliser des macros pour ses
>evenments, je trouve l'argument un peu faible.
Les Macros sont portables, et intégrées à l'environnement de compilation.
Le fait qu'initialement le système ai été calqué sur les MFC (citées par Soustrup comme mauvais exemple de librairie C++), n'a pas empéché que la question se repose, et que le choix du "minimum" technologique ai été fait pour des raisons de compatibilités (comme le choix de ne pas utiliser les containeurs et les strings de la lib standard).
Le choix de QT d'un précompilateur extérieur défrise pas mal de monde en ajoutant au langage des extensions non standard. A la limite à ce stade on peut aussi faire du C++/CLI, mais c'est un choix.
Personnellement, je préfaire dans un projet utiliser des outils approprié à leur spécialité, quitte à ajouter quelques classes uniformisant le style et isolant les différentes libs la ou c'est nécessaire qu'un framework qui me fournit tout mais me coince radicalement.
Et dans le style, wx me suffit (mais les projets sur lesquel je bosse sont rarement trés lourdement orientés IHM).
>Ca plus les problemes specifiques plateformes, ca fait quand meme un
> bagage assez charge pour un toolkit "moderne".
> Je continue a preferer Qt ou tout est super bien integre et on a pas
> l'impression de remonter dans le temps quand on developpe.
C'est un choix personnel, d'un autre coté je suis un amateur de "vieilleries" question d'habitude.
[^] # Re: Je me marre
Posté par tanguy_k (site web personnel) . Évalué à 4.
Ba justement moi c'est la facon Qt de gerer les slots/signaux que je trouve pourrie. Ca utilise le preprocesseur, c'est pas du C++. Impossible d'utiliser des outils avances de modeling parceque l'outil reconnait le C++ pas un truc bidouille. Quand on programme en Qt on se retrouve avec des outils genre vim, emacs, notepad...
On est au 21e siecle, moi je veux utiliser UML, OCL, round-trip engineering... parceque je programme beaucoup beaucoup mieux et plus vite avec.
Sans compter que pour utiliser les classes XML, reseau, string, timer ect... on doit se tapper TOUTE la lib Qt. Oui je sais dans Qt4 ca sera separe (bien separe??) mais en attendant ca fait 10 ans que tout est lie et c'est franchement crado.
Mon avis: Qt est la moins pire des librairies graphiques C++ donc je l'utilise et au final c'est pas mal du tout.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 1.
Tu sais, le C++, c'est beaucoup de choses. Il y a au moins 5 a 6 facons completement differentes de programmer en C++. Ca part du mec qui fait du C avec un objet par ci par la pour dire que c'est objet, au mec qui fait de la meta-programmation a coup de template (on peut calculer la suite de fibonacci avec juste une phase de compilation, genial non ?).
Cela dit, je suis d'accord, c'est pas du C++ pur puisqu'on invente un nouveau paradigme de programmation. Mais les template aussi ont apporte un nouveau paradigme de programmation. Je prefere les signaux et slots, parce que au moins, je comprends comment ca marche (j'ai jamais rien compris aux template), et que ca me sert au quotidien.
Pour ce qui est du modeling, je suis d'accord que les "slots:" foutent la merde dans les classes. Pour moi, c'est un probleme inherent au C++. Avec d'un cote les macros, de l'autre cote les template, et d'un troisieme cote les pointeurs un peu tordu, on arrive a une syntaxe qui est hyper complexe, ce qui fait qu'il est tres difficile de l'utiliser avec des outils de meta-programmation. Java au contraire, a une syntaxe tres simple et deterministe, ce qui fait qu'on voit fleurir des outils de toute sorte: refactoring, programmation orientee aspect, introspection, etc etc.
[^] # Re: Je me marre
Posté par tanguy_k (site web personnel) . Évalué à 2.
> Tu sais, le C++, c'est beaucoup de choses.
Je ne suis pas contre l'utilisation du preprocesseur, mais faut avouer qu'ecrire ca:
class Toto : public QObject {
Q_OBJECT
public slots:
void activate();
signals:
void activated();
};
Malheureusement aucun outil du type Rational Rose, Together ect... ne le supporte. Ce n'est pas l'implementation qui est changee en utilisant le preprocesseur mais carrement la declaration d'une classe !
Sans compter qu'il y a aussi des problemes tordus du style: il faut heriter de QObject en premier sinon ca marche pas.
Trolltech explique pourquoi ils utilisent le preprocesseur (http://doc.trolltech.com/3.3/templates.html(...) ), pas de probleme je ne suis pas contre mais de grace c'est franchement crado de modifier la declaration d'une classe surtout que l'on peut faire autrement cf libsigc++/boost/sigslot/SlotSig. Pour le moment beaucoup de developpeurs n'utilisent pas vraiment UML et les IDE qui vont avec mais c'est clairement l'avenir.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 2.
Il faudrait trouver une syntaxe qui sois discrete. Surtout que slots: et signals: sont vires a la compilation. Ils ne servent que pour le mocm pour qu'il comprenne de quoi li retourne. Je te suggere de faire un rapport de bug a Trolltech. Le mieux, c'est si tu fais quelques essais pour leur proposer une nouvelle syntaxe. Genre:
class Toto : public QObject {
PSEUDO_TYPE Q_OBJECT; // hey, I look like a variable declaration
/* public slots: */
void activate();
/* signals: */
void activated();
};
Sinon, tu peux probablement "patcher" le moc, ca doit pas etre si complique que ca. Il faut juste trouver la ligne ou il cherche les "signals:" et remplacer ca par autre chose.
[^] # Re: Je me marre
Posté par Christophe Renard . Évalué à 6.
La nouveauté est juste un nouveau sizer qui apparemment (je n'ai pas utilisé la version 2.6 et pas suivit les 2.5.x) se comporte plus ou moins comme la TABLE HTML pour disposer les widgets.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . Évalué à 3.
# Mouai ...
Posté par harbort1 . Évalué à 6.
... pour un framework qui copie les MFC ... bof bof !
Pour l'avoir essayé, j'ai pas trouvé ça génial ... le code final n'est pas super lisible et il reprend tous les mauvais côtés des MFC (dont les horribles tables pour associer un événement à une fonction/méthode).
En plus il cherche les problèmes en voulant être multi-système + multi-toolkit, en répétant en ça les erreur du tookit de Java 1.1 ! Pour rappel, pour ce toolkit, il fallait systématiquement tester l'interface graphique sur tous les sytèmes X tous les toolkits sous-jacents possibles pour être sûr que ce soit utilisable. En effet, les toolkits/systèmes ont souvent des comportements légèrement différents qu'il n'est pas possible d'abstraire totalement. Et c'est bien ce que j'ai pu observé pour des applis développées sous windows principalement et qui ne fonctionnaient pas correctement sous linux probablement pour des causes de petites différences entre les toolkits !
Pour un nouveau dév en C++, jamais je ne conseillerai ce framework là ! Qt est bien plus abouti et maintenant qu'il est disponible en GPL sur toutes les plateformes, je ne vois pas ce qui pourrait géner son adoption !
Sinon bien sûr, Gtk est aussi un très très bon toolkit (mais pas en C++), et en ce qui concerne Python l'export est fait de manière très intelligente !
Enfin, tout ça pour dire que vraiment je ne comprends pas l'engouement pour ce toolkit qui est de conception ancienne comparée à l'état de l'art en conception de toolkits (avec par exemple gtk ou Qt) et qui répète les erreurs du passé (comme c'est déjà trop souvent le cas en informatique).
[^] # Re: Mouai ...
Posté par Antoine . Évalué à 4.
Tu as peut-être manqué la partie la plus importante : « elle se "link" avec la bibliothèque graphique de la plate-forme et prend donc l'apparence de celle-ci. » Avec wxWidgets, ton appli est une appli native Windows sous Windows, une appli native GTK2 sous Linux, une appli native MacOSX sous MacOSX... Tout cela ne me semble pas trop possible avec GTK et Qt à l'heure actuelle.
Sinon, oui, wxWidgets n'est pas ce qui se fait de plus novateur et pratique à utiliser comme bibliothèque graphique ; mais c'est la seule bibliothèque libre à ma connaissance à avoir la caractéristique citée ci-dessus. Quant à l'aspect "framework", quand on programme en Python, il est assez inutile...
[^] # Re: Mouai ...
Posté par harbort1 . Évalué à 4.
Je ne l'ai pas du tout raté : c'est justement ce que je lui repproche ! Avec ce principe, tu dois tester ton interface graphique avec tous les toolkits et tous les systèmes supportés si tu veux être sûr que ça marche. Encore une fois, Java 1.1 avait fait la même chose et ils en sont (heureusement) revenu.
Le gros problème des IHM (Interfaces Homme Machines) est qu'elles sont très sensibles au détail. Du coup je préfère 100x développer une IHM avec Qt et avoir le même look'n'feel sous linux et sous windows qu'avoir une IHM qui tourne bien avec Linux/Qt parce que je l'ai développé comme ça et me rendre compte qu'avec Gtk ça marche pas du tout parce que les zones d'éditions de textes ne sont pas gérées pareil par exemple, et les différences seront encore plus grandes sous Windows et Mac OS X.
Enfin, vouloir faire ça c'est s'imposer un surcroit de travail important puisqu'il s'agit non plus d'utiliser des primitives assez simples du système dans un noyaux graphique le plus petit possible et ne porter que ça (le reste reposant sur ce noyaux) mais tout redévelopper pour chaque toolkit pour que ça ait le "look'n'feel" du toolkit en question ! Et qui dit surcroit de travail, dis aussi surcroit de bugs (puisque dans ce cas il y a aussi surcroit de lignes de code).
Non, vraiment c'est une mauvaise idée !
[^] # Re: Mouai ...
Posté par Antoine . Évalué à 4.
C'est vrai pour n'importe quel logiciel multiplateforme.
Aucun programmeur sérieux ne proclame que son application est compatible Windows (ou Linux, MacOS...) s'il ne l'a pas testée avant sous cet environnement. En pratique il y a trois environnements majeurs à considérer : Windows, Linux/GTK2, MacOSX/Aqua.
C'est vrai qu'à l'usage wxWidgets oblige à un peu de debug pénible pour lisser les différences de comportement Windows/Linux/..., mais c'est plutôt dû à un très gros manque de finition de wx qu'à une impossibilité technique.
vouloir faire ça c'est s'imposer un surcroit de travail important
Pour qui ? Pour les développeurs de wxWidgets, peut-être, mais ils l'ont choisi et tant mieux pour nous ;)
Le gros problème des IHM (Interfaces Homme Machines) est qu'elles sont très sensibles au détail.
Là je suis d'accord. Mais avant d'être sensible au détail, il faut déjà que ça fonctionne dans les grandes lignes. GTK sous MacOSX, je n'ai pas l'impression que ça s'intègre très bien graphiquement...
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . Évalué à 4.
J'ai fait pas mal de portages Qt windows / linux dans les deux sens. Zero probleme, zero bug, en dehors des conneries du compilateur de Visual.
<< C'est vrai qu'à l'usage wxWidgets oblige à un peu de debug pénible pour lisser les différences de comportement Windows/Linux/..., mais c'est plutôt dû à un très gros manque de finition de wx
>>
S'il y a un manque de finition, c'est justement parce qu'il faut un travail tres important pour arriver a un bon resultat. Avec wxWidget, plus le toolkit progresse, plus il y a de boulot puisqu'il faut valider tous les widgets et tous les changements sur toutes les plateformes (etant donne que leur implementation varie de plateforme en plateforme).
Sous Qt, a l'inverse, plus le toolkit progresse, moins il y a de boulot. Une fois que tu as porte QWidget, tu as porte Qt sur une autre plateforme. Ensuite, tous le reste de Qt ne depend que de fonctionnalites Qt et n'expose pas de bug specifique plateforme.
En plus, avec les plateformes recentes comme KDE, Windows XP ou MacOS X, l'api de style des widgets est accessible et Qt prend donc une apparence native, exactement comme avec le toolkit de la plateforme.
> > vouloir faire ça c'est s'imposer un surcroit de travail important
> Pour qui ? Pour les développeurs de wxWidgets, peut-être, mais ils l'ont choisi et tant mieux pour nous ;)
Les utilisateurs payent puisque plus de travail pour les developpeurs, ca veut dire plus de risque de prendre du retard, d'intreoduire des bugs, etc etc.
Pour prendre une analogie, avant les bindings gtk etaient generes "a la main". C'etait l'horreur puisque ceux-ci avaient tous du retard sur Gtk ou Gnome, etaient super difficile a maintenir, etc etc. Maintenant, il y a un moteur de generation de binding pour Gtk et il suffit de faire le travail une fois sur le moteur pour recuperer des bindings pour la derniere version de Gtk dans une plethore de langage. C'est beaucoup plus efficace et de meilleure qualite.
[^] # Re: Mouai ...
Posté par Christophe Renard . Évalué à 1.
wxWidgets à des défauts, mais ce que tu lui reproches est plus un choix de politique, et franchement, ton approche n'est pas sans défauts.
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . Évalué à 2.
Quand les API de style natif ne sont pas disponibles, il y a des emulations de tres tres bonne qualite, capables de blouser tout le monde sauf le type qui developpe depuis 10 ans sur ladite plateforme.
[^] # Re: Mouai ...
Posté par TImaniac (site web personnel) . Évalué à 7.
C'est simple : on promet au développeur l'impossible, à savoir un toolkit multi-plateforme qui s'intègre partout, en utilisant les libs natives mon bon monsieur.
Mais à l'arrivé on a un bousin qui ne sait toujours pas faire de GTK2 sans fuite de mémoire, une imitation des widgets windows par "émulation" qui n'a strictement rien à voir avec le toolkit natif sur les Unix, une architecture, comme tu le fais très bien remarqué, copiée sur les MFC (pour attirer le chaland), et comble de bonheur il enlarge tellement votre penis qu'il vous propose un framework complet jusqu'à la couche réseau qui lie fortement votre application à ce framework.
[^] # Re: Mouai ...
Posté par Frédéric Lopez . Évalué à 3.
C'est peut-être parce que les alternatives ne conviennent pas forcément à tout le monde.
QT n'était pas libre jusqu'il y a peu de temps et coûte de toute façon très cher si on veut écrire une application propriétaire avec. D'autre part, on ne peut pas vraiment dire que GTK+ soit mature sous MS Windows et la licence utilisée pose également des restrictions pour les développements propriétaires.
Sans oublier le fait que wxWidgets (wxWindows) existe depuis beaucoup plus longtemps que la plupart des toolkits existants et qu'il permet de capitaliser sur la pratique en programmation MFC, puisqu'il est basé sur les mêmes principes.
Alors bon, qu'il ne soit pas parfait est une chose, mais il y a visiblement beaucoup d'utilisateurs satisfaits, du coup j'ai un peu du mal à comprendre votre acharnement dessus. Si ça ne vous convient pas, passez votre chemin, mais ne vous sentez pas obligés d'en dégoûter les autres.
[^] # Re: Mouai ...
Posté par Olivier jolly . Évalué à 5.
Depuis la version 2.4, on n'a plus de support des plus vieux windows (95/98, ptet meme ME) et l'installeur n'est pas top top (un chouilla lourd et un besoin de rebooter ou de relancer la session pour que la mise à jour du PATH pour prendre en compte les .dll soit effective).
De plus, j'ai régulièrement des utilisateurs qui ont des problèmes avec pango, qui sont parfois réglés par des renommages violents des .dll incriminés (c'est un utilisateur qui m'a remonté ça, j'en ai trouvé aucune trace dans le bugzilla & cie).
Alors oui, c'est peut être une librairie à la philo moisie, il va falloir que je dépoussière mon wine pour tester le port windows au lieu de faire confiance à l'uniformité du look'n feel de gtk+, mais au moins ca supportera les vieux windows, ca obligera pas mes utilisateurs windows à télécharger et installer, parfois avec peine, un gtk+, et ca pourra supporter un éventuel port mac os x vu que gtk+ en natif de ce côté là a pas l'air d'être utilisable avant un bon bout de temps. Donc un gros dilemme en perspective sachant que j'aurai aimé promouvoir gtk+...
[^] # Re: Mouai ...
Posté par Christophe Renard . Évalué à -1.
[^] # Et FOX-toolkit ?
Posté par karteum59 . Évalué à 4.
Techniquement, il serait plutôt à rapprocher de QT (C++, facile à utiliser (mais sans MOC), multi plates-formes, dessine lui-même ses trucs contrairement à wx, etc...), mais
- LGPL
- très complet pour la GUI. Contrairement à QT ou wx il ne cherche pas à être un framework complet mais se concentre uniquement sur la GUI.
- léger & rapide, mais pas encore thémable (look&feel "winowsien" par défaut. On aime ou on n'aime pas... Pour ma part ça ne me gène pas trop vu ses autres qualités)
- bien supporté sous d'autres langages (notamment ruby)
- et surtout, très stable bien qu'en évolution assez active.
-> http://www.fox-toolkit.org(...)
Par contre je dois avouer que les fonctionnalités annoncées de QT4 sont séduisantes (notamment le canvas OpenGL, à faire pâlir Rasterman et son evas. J'en ai rêvé, ils l'ont fait !). QT aura toujours un cran d'avance, mais ça se paye ! (du moins si on développe des applis commerciales)
[^] # Re: Et FOX-toolkit ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Justement, dans un contexte commercial, si tu fais gagner un mois de dev a ton developpeur, tu as paye 2 fois ta licence Qt. Je pense honnetement que Qt fait gagner plus que ca sur un projet de quelques mois, et que donc son prix se justifie largement. Dans un contexte commercial !
[^] # Re: Et FOX-toolkit ?
Posté par Ludovic Pénet . Évalué à 4.
Le prix nul de wxWidgets n'est pas son seul avantage pour un développement propriétaire. Sa licence non-gauche en fait un canevas de développement que chacun peut faire évoluer à sa guise sans avoir à modifier la licence du bignou reposant sur wxWidgets.
Que se passe-t-il en effet si la version de Qt disponible sous licence propriétaire prend une direction qui ne te convient pas ? Avec wxWidgets, ton indépendance est garantie.
[^] # Re: Et FOX-toolkit ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Je ne comprends pas ce qui se cache derriere cette phase. Avec la version commerciale, tu peux utiliser la licence que tu veux pour ton soft, a condition de ne pas exposer l'api Qt. Et tu as les sources, donc si ca evolue pas dans le bon sens, tu as le droit de le faire evoluer toi-meme.
Ton independance reste garantie.
[^] # Re: Et FOX-toolkit ?
Posté par Croconux . Évalué à 5.
C'est à mon avis son plus gros défaut : Une appli FOX ne ressemble à aucune autre appli que ce soit sous Windows ou Linux c'est moche partout. Dans la même veine il y a aussi TK. C'est simple, léger, ça marche partout mais c'est moche. Il y a peu de toolkits qui peuvent se vanter de se fondre dans le paysage (Gtk et Qt en font partie).
[^] # Re: Mouai ...
Posté par Antoine . Évalué à 2.
De quels widgets parles-tu ??
[^] # Re: Mouai ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Mouai ...
Posté par Antoine . Évalué à 3.
Tu n'es pas obligé d'utiliser la couche réseau fournie par wx, tu sais. Tu peux utiliser une autre bibliothèque d'abstraction réseau, comme ACE en C++ ou Twisted en Python.
[^] # Re: Mouai ...
Posté par Christophe Renard . Évalué à 1.
> voir avec le toolkit natif sur les Unix,
Car il y'a un toolkit natif Unix ? même en remplacant Unix par X11, je ne vois pas.
Xt/Intrinsinc ? Motif ? Athena ?
>il vous propose un framework complet jusqu'à la couche réseau
>qui lie fortement votre application à ce framework.
la force d'une proposition c'est qu'elle n'est pas un obligation, rien ne t'oblige à utiliser exclusivement wx pour toutes les fonctionalités.
En matière de réseau, si on se limite à wx on ne va pas loin.
Mais si on a uniquement besoin de fonctions "basiques" elles sont disponibles.
[^] # Re: Mouai ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Il fallait comprendre "le toolkit de l'environnement courant sur mon poste de travail Unix/Linux en ce moment".
[^] # Re: Mouai ...
Posté par Romain Guy . Évalué à 4.
[^] # Re: Mouai ...
Posté par Adrien Bourdet . Évalué à 4.
Le fait qu'on ne puisse pas faire d'application propriétaire sans devoir payer une licence.
Dans la boite où je bosse, on voudrait migrer des MFC vers un toolkit qui nous permettre de rendre nos appli graphiques multi-plateformes.
D'un côté il y a des toolkits intéressant : wxWidget, Qt (Gtk, mais on préfère le C++), mais on ne fait pas des applis GPL, donc on est obligé d'inverstir si on veut du Qt.
De plus, même si on veut des appli multi-plateformes, on développe majoritairement avec VisualC++, donc la compilation et le déboggage avec Qt, je sais pas trop ce que ça va donner (au vue du code que j'ai vu plus haut, et qu'on doit préprocesser).
Donc je trouve que Qt a l'air vraiment bien (GPL, "propre", interface avec python), mais il existe bien un frein dans le cadre de mon travail.
PS: je rappelle qu'avec VisualC++, on peut déboguer et recompiler des parties de code à la volée, au cours du déboguage. Si quelqu'un me dit qu'on peut faire la même chose en utilisant Qt, ou avec un environnement de développement libre, ça m'intéresserai vraiment.
[^] # Re: Mouai ...
Posté par Frédéric Lopez . Évalué à 4.
Il y a toujours gtkmm (http://www.gtkmm.org/(...) ) si vous voulez utiliser GTK+ avec du C++. Il support le paradigme signal/slot (comme QT) avec libsigc++ et il est sous licence GNU LGPL, ce qui permet de l'utiliser dans des applications propriétaires.
[^] # Re: Mouai ...
Posté par Maz (site web personnel) . Évalué à 2.
[^] # Re: Mouai ...
Posté par Croconux . Évalué à 2.
Une des solution possible serait de séparer l'IHM du moteur du logiciel. Comme ça tu peux garder ton logiciel sous la licence se ton choix et fournir une interface Qt sous GPL. Ca permettrait aussi à d'autres logiciels de venir se brancher sur ton soft et de l'utiliser comme un service. C'est une des choses que je trouvais prise de tête sous Windows : Tous les programmes sont conçus pour tourner seuls dans leur coin. La seule façon d'utiliser un composant d'une autre appli c'était COM (que du bon).
[^] # Re: Mouai ...
Posté par Philippe F (site web personnel) . Évalué à 4.
Ca se passe tres tres bien. Qt fournit un petit plugin pour Visual qui permet de gerer facilement les moc et les fichiers d'interface graphique (generes par Qt Designer). Ca fait plusieurs annees que je developpe avec Qt + Visual et je n'ai aucun probleme. C'est meme mon environnement favori, a cause l'excellente qualite du debugger de Visual (dommage que gdb soit a des annees lumieres).
> on ne fait pas des applis GPL, donc on est obligé d'inverstir si on veut du Qt.
De fait. Mais si vraiment c'est important pour vous d'avoir des applis multi-plateformes, l'investissement est rentable. Avec Qt, non seulement tu vas vite quand tu developpes, mais en plus, ca marche partout sans aucun effort. Je suis vraiment epoustoufle par la qualite de ce toolkit. A mon avis, si tu cherches une alternative moins cher, tu vas au final perdre du temps dans ton developpement. N'oublies pas que un mois-homme, c'est plusieurs licences Qt.
> Si quelqu'un me dit qu'on peut faire la même chose en utilisant Qt,
Qt ne change rien a ca, c'est une fonctionnalite du compilateur de Microsoft. Comme quoi, c'est pas des manchots quans ils veulent.
[^] # Re: Mouai ...
Posté par Zenitram (site web personnel) . Évalué à 5.
Et moi je le conseillerai, justement du fait de ce que tu lui reproches :
- je veux une appli win32 qui ressemble a du win32, pas un dessin de Linux affiché sur du win32. Mes utilisateurs apprécient.
- Ce que tu veux (un dessin générique quelque soit l'OS, plutot qu'un dessin dépendant lde l'OS), ca existe en WxWidgets, ca s'appelle WxUniv. Donc tu laisses le choix, je prefere 1000 fois une bibliotheque qui me laisse le choix, plutot qu'une bibliotheque qui m'impose un choix.
Qt est bien plus abouti et maintenant qu'il est disponible en GPL sur toutes les plateformes
Et boom : encore une raison pour laquelle je rejette Qt :
- Deja, seul Qt4 va etre GPL, et Qt4 n'est pas encore sortie. Donc Qt n'est pas libre sous Win32
- Qt4 est GPL, et moi j'ai besoin d'avoir plus de liberté, la licence de WxWidgets m'en laisse plus, je peux décider de ma licence (oui, le libre ca va bien, mais moi ca ne me fait pas vivre, et c'est comme le point du début : je prefere avoir le choix, LGPL se transforme en GPL, et pas l'inverse). C'est un choix philosophique non partégé, mais il existe...
qui répète les erreurs du passé
Moi, je ne trouve pas... Chacun voit les erreurs de passé ou il veut, je prefere programmer en Wx plutot qu'en GTK (pas de C++, et après on dit que c'est moderne alors que le C, ca date un peu...) ou Qt (le bordel pour compiler)
Chacun son choix, merci de ne pas dénigrer les autres si ils ne font pas ce que tu aimes, peut-etre qu'un jour tu changera d'avis... ;-)
# et la commande pour compiler...
Posté par scls19fr (site web personnel) . Évalué à 7.
g++ hello.cc -o hello `wx-config --libs` `wx-config --cxxflags`
c'est bête mais pour donner l'envie de tester... c'est mieux
et pour éviter que ça gueule à la compil il faut aussi
_(...)
autour des chaînes de caractères (au moins à partir de la version 2.5... me semble-t-il)
wxString(..) ou un truc du genre marche aussi mais j'utilise _(...) ça ser aussi pour l'internationalisation (i18n)
[^] # Re: et la commande pour compiler...
Posté par Maxime (site web personnel) . Évalué à 2.
C'est vrai que c'est mieu pour tester !
[^] # Re: et la commande pour compiler...
Posté par quadra38 . Évalué à 0.
bien décidé à me mettre au C++ sous Linux j'ai cherché qq exemples simples et je pensais avoir trouvé ?
ben non, voici les erreurs qui sortent lors du gcc++
je ne comprends pas pourquoi cela ne marche jamais du 1° coup !!
merci de me guider
[^] # Re: et la commande pour compiler...
Posté par mosfet . Évalué à 1.
En gros tu passes a ton constructeur une chaine de caractere alors qu'il s'attend a recevoir une reference sur un un objet wsString.
Le plus simple est de declarer un wsString strToto et de passer cet objet la ou il faut.
[^] # Re: et la commande pour compiler...
Posté par quadra38 . Évalué à 0.
mais j'ai des erreurs de "conversion" d'arguments
que dois-je entrer pour corriger cela
merci
[^] # _(...)
Posté par Zenitram (site web personnel) . Évalué à 1.
_(...)
autour des chaînes de caractères (au moins à partir de la version 2.5... me semble-t-il)
Rien a voir avec WxWidgets, c'est un pb C/C++ plutot :
- il faut "xxx" en ANSI
- il faut L"xxx" en UNICODE (caracteres chinois/japonais/russes en meme temps)
- mettre _("xxx") permet d'avoir un code portable dans les deux versions : necessaire si tu compiles dans les deux versions (Unicode n'est pas supporté par Win9X par exemple, mais c'est mieux l'Unicode dans les autres cas), sinon tu ne le mets pas. Donc non _(...) ne sert pas a l'internationnalisation, juste à typer tes caracteres :) (ce qui aide effectivement au 18n, faut l'avouer)
PS : la bonne chose si c'est du WxWidgets pur, c'est wxT(...), et si c'est du C/C++ "classique", c'est _T(...), et non pas _(....)
[^] # Re: _(...)
Posté par scls19fr (site web personnel) . Évalué à 1.
[^] # Re: _(...)
Posté par scls19fr (site web personnel) . Évalué à 0.
# Cette librairie est géniale
Posté par Victor STINNER (site web personnel) . Évalué à 4.
L'utilisation de la STL étant un truc prévu depuis 2 ou 3 ans. Je suis très content de voir que wxWidgets a enfin fait le bon choix. Pour information, ça n'avait pas été fait avant tout simplement parce les compilateurs gêraient plutôt mal les templates (base de la STL).
Pour info, il est possible de "charger" une interface depuis un fichier XML (extension XRC). Pour dessiner l'interface, on peut utiliser wxGlade (pas testé) ou wxDesigner (très bon, complet, mais payant et proprio).
Je trouve que la documentation est bien écrite.
Ah oui, il faut aussi noter que la librairie date de 1992 et est plus utilisée qu'on ne le pense. Elle est très complète.
@+ Haypo
[^] # Re: Cette librairie est géniale
Posté par scls19fr (site web personnel) . Évalué à 1.
wxGlade
wxDesigner
mais aussi
XRCed
DialogBlocks
VisualWx
[^] # Re: Cette librairie est géniale
Posté par scls19fr (site web personnel) . Évalué à 0.
wxGlade
wxDesigner
mais aussi
XRCed
DialogBlocks
VisualWx
[^] # Re: Cette librairie est géniale
Posté par zeSixty4Douille . Évalué à 1.
Faire abstraction de l'OS, c'est le but de tout le monde (sauf de la MFC).
[^] # Re: Cette librairie est géniale
Posté par brouillon . Évalué à 1.
Tu peux preciser stp.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.