Discussion :

[f56bre]

Bonjour,

Je pense que depuis le passage de la license de Qt en LGPL celle ci a pris un net avantage sur wxWidget cependant qu'en est il des performances.
Quelqu'un a t'il déjà testé et comparé les dernières versions de ces deux librairies?
Quels sont leur points forts / points faibles?

[Shaidak]

Bonjour,

Pour être tout à fait honnête, je pense sincèrement qu'elles ne sont pas comparables sur l'ensemble de leurs possibilités. Qt permet d'obtenir quelque chose de façon bien plus rapide et plus professionnelle que wxWidgets. On sent que l'outil est bien plus abouti, qu'il y a bien moins de fonctionnalités expérimentales, que la question du portage ne se pose même pas tant elle est évidente et ... wxWidgets est grande ... Qt est gigantesque

En revanche, j'aurais tendance à dire que l'on peut obtenir, pour la majorité des projets et au niveau de l'interface uniquement, quelque chose de similaire. Il suffit de voir tous les projets basés sur wxWidgets.

Pour ma part, je suis passé à Qt dès que le changement de licence a eu lieu, et je ne regrette vraiment pas. Tout me paraît plus "propre", plus robuste, en bref, plus "pro".

Pour ne pas faire le classique points forts/points faibles, je vais citer ce que Qt a de plus sur wxWidgets (l'inverse est difficilement trouvable ) :

- C'est une bibliothèque très aboutie (pas/très peu de méthodes qui marchouillent ou qui posent des problèmes de portabilité).
- Un éditeur (Qtcreator) bien plus puissant (et pratique) que celui de wxWidgets permettant de ne pas perdre de temps sur des détails.
- Une communauté bien plus importante.
- Ce n'est pas forcément essentiel, mais cela dénote une fois de plus la qualité du produit : le sdk complet de la bibliothèque est téléchargeable et évite d'avoir à compiler soi-même les sources si l'on ne souhaite pas se soucier de cette formalité.

Bon, je pense que jvais m'arrêter là et j'espère ne pas avoir été trop subjectif ...

[f56bre]

Merci pour ta réponse Shaidak.
Quelqu'un a t'il déjà mis le nez dans le code de ces deux librairies? Si oui, qu'en est il ressorti?

[poukill]

Quelqu'un a t'il déjà mis le nez dans le code de ces deux librairies? Si oui, qu'en est il ressorti?

Je crois qu'il ne faut pas tout mélanger...
Le code, c'est le code. l'implémentation en fait. Et ce qui intéresse l'utilisateur c'est l'interface, i.e les méthodes et les abstractions...

Au fait, il y a déjà eu des débats Qt / Wxwidget. Recherche dans le forum.

[IrmatDen]

Je n'ai pas mis les mains dans le code de WxWidgets, mais je peux te garantir que celui de Qt est extrêmement propre. Il m'arrive régulièrement de le lire pour 2 raisons:
1. comprendre un bug dans mon code
2. ou comprendre comment est implémentée une feature, par pure curiosité

Le gros pour de Qt, à mes yeux, ça va de soit, c'est que la majorité des traitements intéressant passent par un système d'observateurs, contrairement aux messages maps WxWidgets qui m'ont immédiatement rappelé les MFC.

Voilà, l'avis d'un pro-Qt jusqu'au bout des ongles

Mais, ce que tu as de mieux à faire est, je pense, prendre les deux libs, faire leur tutos respectifs, puis faire un micro-projet dans les deux si les tutos ne t'ont pas permis de délibérer. Après tout ça, tu sauras avec quelle lib tu te sens le mieux, tout en sachant davantage sur la permissivité de chacune.

[Sylvain Togni]

J'ai beaucoup utilisé wxWidgets. C'est une bibliothèque sympathique car entièrement communautaire, elle n'appartient à aucune société.

Mais elle est en dessous de Qt sur de nombreux points, et depuis le passage de Qt en LGPL, elle n'a presque plus aucun avantage. A tel point que je ne sais pas si elle va continuer à vivre.

[Shaidak]

Elle continuera de vivre ou la limite de survivre tant que des applications l'utiliseront, bien qu'en fait, si l'on prend l'exemple de Code::Blocks, il n'utilise même pas la dernière version, loin de là, donc au final, je me demande si elle n'est pas déjà en train de survivre

[Rexxar79]

Un des avantages de wxwidget c'est qu'on peut la lier statiquement avec l' application et ne pas avoir 15 Mo de dll à trainer avec l'executable. Dans pas mal de cas ce n'est pas un problème mais si on a besoin de distribuer l'application à beaucoup de monde ça devient un avantage non négligeable.

[Matthieu Brucher]

Un des avantages de wxwidget c'est qu'on peut la lier statiquement avec l' application et ne pas avoir 15 Mo de dll à trainer avec l'executable. Dans pas mal de cas ce n'est pas un problème mais si on a besoin de distribuer l'application à beaucoup de monde ça devient un avantage non négligeable.

Qt aussi permet la liaison statique... (t'as vu où que ce n'était pas possible ? 99.9% des bibliothèques le permettent)

[Sylvain Togni]

Qt aussi permet la liaison statique... (t'as vu où que ce n'était pas possible ? 99.9% des bibliothèques le permettent)

Elle le permet techniquement, mais pas forcement juridiquement. La licence de la version gratuite de Qt (LGPL) interdit la liaison statique à un programme non GPL.

[Matthieu Brucher]

Et comme wxWidgets est sur la même license, c'est kifkif, non ?

[Shaidak]

Certes, donc de ce point de vue, ça serait un avantage pour wxWidgets.

Cependant, pour ce qui est du gain en taille, une liaison statique impliquant une augmentation de la taille de l'exécutable, cela revient au même non (je n'ai jamais fait de liaisons statiques ... trop de contraintes) ?

[3DArchi]

Et comme wxWidgets est sur la même license, c'est kifkif, non ?

Il me semble que la licence wxWidgets est plus permissive. Elle reprend la LGPL mais la modifie explicitement pour permettre son utilisation dans les programmes commerciaux sans contraintes :

2. The exception is that you may use, copy, link, modify and distribute under your own terms, binary object code versions of works based on the Library.

[dourouc05]

Il me semble que la licence wxWidgets est plus permissive. Elle reprend la LGPL mais la modifie explicitement pour permettre son utilisation dans les programmes commerciaux sans contraintes.

Qt n'impose qu'une seule contrainte à ces programmes, due à la licence LGPL : il faut redistribuer les modifications effectuées aux sources de Qt en LGPL. Ce qui n'est quand même pas très exigeant.

[Shaidak]

Une autre question sur laquelle je ne me suis pas encore penché, pour wxWidgets, il y a possibilité d'utiliser un fichier xml externe (*.xrc).
Y a-t-il un équivalent pour Qt ou non ? Pour le moment je n'ai pas trop cherché à ce niveau mais si c'était le cas je serais plus qu'intéressé Sinon, et bien autre avantage pour wxWidgets

[IrmatDen]

Oui, il s'agit des fichiers .ui.

[Shaidak]

Hmm ... honte à moi, j'aurais dû me douter que ce .ui fonctionnait de la même manière que le .xrc et c'était gros que Qt ne dispose pas de cette fonctionnalité

Donc finalement, je n'ai rien dit le seul avantage à mes yeux de wxWidgets reste certains détails de la licence pour ce qui est de la liaison statique ... et ne l'utilisant jamais ... ça me fait une belle jambe

[dourouc05]

Une autre question sur laquelle je ne me suis pas encore penché, pour wxWidgets, il y a possibilité d'utiliser un fichier xml externe (*.xrc).
Y a-t-il un équivalent pour Qt ou non ? Pour le moment je n'ai pas trop cherché à ce niveau mais si c'était le cas je serais plus qu'intéressé Sinon, et bien autre avantage pour wxWidgets

En fait, Qt propose bien mieux que ça : des ressources intégrées dans l'exécutable, et pas seulement sous Windows. Tu peux avoir des fichiers .qrc (équivalents de .rc), qui seront interprétés par le MOC. Tu peux y mettre n'importe quoi : des icônes, des images, des textes de licence, des archives...

Je ne retiendrai qu'un seul inconvénient à Qt : le MOC, par lequel doivent passer beaucoup de fichiers. Mais c'est automatisé par qmake et par l'intégration à VS, donc cet inconvénient n'a plus beaucoup de poids...

[Rexxar79]

Qt aussi permet la liaison statique... (t'as vu où que ce n'était pas possible ? 99.9% des bibliothèques le permettent)

Désolé de répondre 8 jours plus tard

Comme l'on précisé Sylvain Togni et 3DArchi je parlais de la license, pas d'une limitation technique. Mais ce vrai que j'ai été ambigüe.

La différence c'est que quand on lie une application statiquement à une aplli, l'appli est considéré comme un travail dérivé de la librairie et doit donc être sous LGPL. Une exception a été ajouté à wxWidget pour permettre de lier statiquement.

Pour info c'est le paragraphe 6 qui semble imposer la liaison dynamique en pratique, même si c'est assez peu explicite :
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

La FSF explique aussi ça ici (GPL et LGPL) :
http://www.gnu.org/licenses/old-lice...compatibleLibs

Certes, donc de ce point de vue, ça serait un avantage pour wxWidgets.

Cependant, pour ce qui est du gain en taille, une liaison statique impliquant une augmentation de la taille de l'exécutable, cela revient au même non (je n'ai jamais fait de liaisons statiques ... trop de contraintes) ?

Non car dans une dll, le linker est obligé de mettre le code de toute les fonctions or si une fonction n'est pas utilisée, elle est complètement éliminée lors du link statique.

C'est pour ça qu'un HelloWord.cpp donne un exe tout petit même si il est lié statiquement à toute la librairie standard.