Discussion :

[yan]

Peut être qu'en lançant le débat dans le forum contribuez avec l'aide de tous les membres, on aurais plus de chance ?

On peut toujours profiter de ce nième thread sur les gui (qui n'est pas encore partie en troll) pour commencer. Et ça pourrais alimenter correctement le débat et surtout répondre objectivement à la question de départ.
Surtout que ça semble intéresser du monde. Presque 1000 affichages en 5 jours

[ttone]

Après un passage sur Qt, je fais un tour du côté de Juce, pour des besoins audio. Ca me permet d"éviter un mix Qt+Fmod par exemple, pour une librairies graphiques avec des outils audio/midi, bref un peu plus spécialisée.

Les bons points de Juce, c'est le prix, et aussi des détails intéressants : boutons rotatifs vectoriels, intégration du SVG, et de nombreux points comparable à Qt.

Par contre côté fenêtre de dialogue, je crains que Juce ne propose pas d' "OpenFile" standard à la Qt4, même chose pour le signal-slot qui m'avait été utile sur Qt.

http://www.rawmaterialsoftware.com/

[Alp]

Parmi les choses qui me plaisent dans Qt, personnellement, il y a le système signal-slot. Bien qu'il faille passer par moc, c'est tout de même très utile et on va assez vite quand on a pris l'habitude. Après, les signaux de GTK+/GTKmm sont eux aussi pratiques, question de goût comme le dit Mongaulois.

Par contre, mon avis sur wxWidgets est fait : j'avais commencé par ça pour le GUI en C++... Et qu'est-ce que c'était long de développer avec wx comparé à Qt ou GTKmm ! Surtout les tables d'évènements. Après, ça reste une bonne alternative si les deux autres ne conviennent pas.

Pour FLTK, aucun avis à donner je ne m'en suis jamais servi

[epsilon68]

Parmi les choses qui me plaisent dans Qt, personnellement, il y a le système signal-slot. Bien qu'il faille passer par moc, c'est tout de même très utile et on va assez vite quand on a pris l'habitude. Après, les signaux de GTK+/GTKmm sont eux aussi pratiques, question de goût comme le dit Mongaulois.

j'utilise boost::signal dans le code metier.... Mais tout le temps tenté d'utiliser celui de Qt :-)

[yan]

Salut,
je réouvre ce débat suite à l'annonce de nokia :
Qt 4.5 sous licence LGPL :
http://www.developpez.net/forums/d67...-licence-lgpl/


[edit]
pour tout commentaire lié à l'annonce de nokia et non sur le sujet originale, merci de les poster sur à la suite de l'annonce.
http://www.developpez.net/forums/d67...-licence-lgpl/

[Matthieu Brucher]

On va dire que le seul gros inconvénient vient de disparaître comme par magie

[Alp]

C'est tout bonnement monstrueux. Voilà qui devrait faire réfléchir tous ceux pour lesquels la licence était très handicapante...

[Luc Hermitte]

Pour une société, la licence n'est pas forcément le plus gros problème. Le support est une chose intéressante en l'absence de spécialistes interne sur la technologie.

[Alp]

Pour une société, la licence n'est pas forcément le plus gros problème. Le support est une chose intéressante en l'absence de spécialistes interne sur la technologie.

Tout à fait.
Mais il n'y a pas que les boîtes. Je parle aussi en termes d'utilisateurs du monde libre. Combien de fois j'ai pu lire "Qt je n'utilise pas, c'est contre l'esprit du libre, etc" ?

Je pense que là ça peut faire basculer les choses.

[yan]

Pour une société, la licence n'est pas forcément le plus gros problème. Le support est une chose intéressante en l'absence de spécialistes interne sur la technologie.

Ça dépend de la société et surtout du client.

[Luc Hermitte]

Contre l'esprit du libre ? Je trouve l'approche "GPL ou licence payante" bien plus libriste (au sens politique du libre) que la LGPL qui n'enforce pas grand chose au final vu que cela permet de piller facilement sans même récompenser.

NB: je suis plus BSD ou BSL que GPL dans l'âme, n'allez pas me prêter des convictions que je n'ai pas.

[Alp]

Contre l'esprit du libre ? Je trouve l'approche "GPL ou licence payante" bien plus libriste (au sens politique du libre) que la LGPL qui n'enforce pas grand chose au final vu que cela permet de piller facilement sans même récompenser.

NB: je suis plus BSD ou BSL que GPL dans l'âme, n'allez pas me prêter des convictions que je n'ai pas.

Je n'ai pas dit que je trouvais ce genre de paroles correct, pour moi Qt a toujours été dans un bon esprit. Si tu veux développer dans un cadre pro tu payes, sinon hé bien fais-toi plaisir.
Mais là, pouvoir développer dans un cadre pro sans payer la licence, c'est aussi une bonne chose. Après, si tu veux le support, tu payes... Faut pas abuser non plus.

Mais dans l'absolu, BSD & BSL me plaisent plus. C'est surtout beaucoup moins prise de tête comme licences

[yan]

Contre l'esprit du libre ? Je trouve l'approche "GPL ou licence payante" bien plus libriste (au sens politique du libre) que la LGPL qui n'enforce pas grand chose au final vu que cela permet de piller facilement sans même récompenser.

NB: je suis plus BSD ou BSL que GPL dans l'âme, n'allez pas me prêter des convictions que je n'ai pas.

Perso, j'aime bien cette phrase
http://www.gnu.org/licenses/why-not-lgpl.fr.html

Pourquoi vous ne devriez pas utiliser la LGPL pour votre prochaine bibliothèque
[...]
Le choix de la meilleure licence pour une bibliothèque donnée est une affaire de stratégie, et, est fonction de la situation.

C'est exactement ce qui se passe pour Qt. Qu'elle est l'intérêt pour nokia de garder une licence commercial/GPL ? aucune.
Nokia c'est du hardware et non du dev. La LGPL ça leur permet de fournir un vrai framework de développement totalement gratuit dans son utilisation pour leur futur produit,et qui plus est :
1- une vrai doc
2- historique multi-plateforme (compilation/distribution) que je pense inégalé
3- de très bonne performance
4- fournie un support technique

Il y as même une communauté de développeur : http://maemo.org/

[gege2061]

Si tu veux développer dans un cadre pro tu payes, sinon hé bien fais-toi plaisir.

Attention à la nuance : http://www.developpez.net/forums/d31...t/#post1984451

[loufoque]

La FSF dit ne pas utiliser la LGPL mais plutôt la GPL pour donner un avantage au logiciel libre.
Ça n'a rien à voir avec ce que fait Qt, qui met cette licence en second plan (si tu vas sur le site de trolltech, faut vraiment savoir qu'elle existe pour la trouver, et elle "vendue" comme une genre de version d'évaluation).

[zais_ethael]

Ouaw, ça c'est de la nouvelle, je m'y attendais vraiment pas. Ben je crois que c'est le coup de grace à ma réticence pour passer sur Qt.

[yan]

Ouaw, ça c'est de la nouvelle, je m'y attendais vraiment pas. Ben je crois que c'est le coup de grace à ma réticence pour passer sur Qt.

C'était surement le but

Qt deviens un vrai concurrent à wxwidget et à gtk (utilisé en C++).
Après je ne sais pas si cela sera la même chose avec les autres langages comme python, php, ruby,...
Il me semble que les binding marche beaucoup mieux avec gtk

Je me demande aussi comment va évoluer Qt avec le prochaine standard aussi.

[Matthieu Brucher]

Il me semble que les binding marche beaucoup mieux avec gtk

Pas pour Python en tout cas. Le binding pygtk a toujours des problèmes de threads qui ne passent pas correctement.

Pour PyQt, ça dépend du gars qui est derrière, et comme il en vit, ce n'est pas gagné. Mais comme l'a dit Matthias Ettrich il y a 2 ans, PyQt et tous les autres bindings, ce n'est pas leur problème. Ils ont un moteur de script et voilà.

[loufoque]

Je me demande aussi comment va évoluer Qt avec le prochaine standard aussi.

Il n'évoluera pas.
Le code devrait déjà être entièrement réécrit pour faire les choses comme il faut en C++98...

L'interface de Qt c'est plein de pointeurs et autres horreurs, hein. C'est pas vraiment du RAII.

[Luc Hermitte]

Tu es vache de dire ça. (OK je sors)

Plus sérieusement, ils ont toujours ciblés les vieux compilos et autres compilos exotiques. Je doute que cela change du jour au lendemain.
Je ne vois pas le code de Qt profiter des rvalue references, ou des threads de C++0x avant une dizaine d'année. Ces apports auraient de profondes implications sur le design de la bibliothèque.