Discussion :

[Freem]

Personnellement, quand je parle de Qt, j'ai plus l'impression de parler d'un langage différent qui intègre le C++ comme sous-ensemble ( de la même façon que le C++ intègre le C comme un sous-ensemble, et à l'origine "compilait" un source en langage C via cfront, qui était ensuite définitivement compilé, de la même façon que Qt "compile" en C++ via mok, si je me souviens bien ) que comme un simple framework.

Donc, que Linus aime Qt et pas C++ ne me surprend pas ( pour garder une vision au ras des paquerettes d'un mail sorti du contexte d'une -- voire plusieurs -- discussion sur une mailing list ).

A part ça, tant mieux pour Qt si ça marche. Selon moi, utiliser du C pour gérer des IHM n'est pas vraiment optimal, entres autres à cause du manque de gestion automatisée de la mémoire: malloc/free, ou leurs équivalents bibliothécaires, ça va un temps, mais c'est quand même vachement error-prone.
Ceci dit, j'ai quand même envie de m'inquiéter du manque d'alternatives. A part wxWidgets et GTK, il n'y a pas grand chose d'autre qui soit exploitable à la fois sous linux et windows. Enfin bon, la situation n'a pas vraiment changé de ce point de vue, et ce n'est pas près de s'arranger.

Par rapport au GTK et aux appli qui l'abandonnent, je suppose également que c'est lié au fait que l'on demande au toolkits graphiques de faire de plus en plus de choses, y compris non liées aux contrôles d'une fenêtre. GTK s'enrichissant en conséquence, et le C étant, selon moi, plus complexe à maintenir que du C++ ( grâce, entres autres, à la RAII, aux exceptions et au modèle objet plus propre qu'en utilisant glib ) le code se complexifiant, autant utiliser Qt qui me semble plus maintenable.
A ce sujet, il semble qu'il soit possible d'avoir des tests unitaires d'IHM avec Qt (jamais testé, je viens juste de le découvrir en fait), est-ce possible avec GTK? Sinon, c'est tout de même un argument fort contre GTK.

[loupium]

Et encore, ce n'est que des applications libres (open source...) donc avec une cetaine visibilité.
Car dans un milieu un temps soit peu professionnel/industriel (dont les outils de dev sont rarement divulgués), il me semble que la question ne se pose même plus si l'on souhaite être multiplateforme.

Ce qui rassure avec Qt, c'est sa maturité tout en restant moderne et innovant. Même si la maturité est rarement compatible avec l'innovation comme c'est le cas avec Qt Quick.

Je pense qu'il y a un gros avantage à cela (même si je ne l'ai pas encore testé) : il doit très certainement être assez simple d'utiliser des librairies JS pour compléter les fonctionnalités de QML (édition de fichier ODF, PDF, ...)

Malheureusement non, les librairies JS sont pour la plupart très orientés web et donc très dépendantes de l'environnement d'un navigateur web.

[Jiyuu]

Malheureusement non, les librairies JS sont pour la plupart très orientés web et donc très dépendantes de l'environnement d'un navigateur web.

C'est dommage, car pour moi Qt à malgré tout un gros point noir : impossible de générer, éditer, ... des fichiers ODF.
En tout cas j'ai pas trouvé, et j'avais un espoir avec JS. Il va falloir que je continue à me contenter des outils proposés via Python

[Bktero]

Je suis de loin l'évolution de Qt depuis quelques années, sans jamais avoir eu l'occasion de m'en servir autrement que pour quelques petits projets perso.

Je me demande si l'adoption de Qt n'est pas aussi facilité par le fait que Qt n'est pas qu'un framework pour la partie GUI. Il existe aussi des modules pour gérer du XML (j'ai découvert Qt en cherchant des parseurs XML) et pour gérer des BDD (que j'ai utilisé dans ma première application Qt). Pensez-vous que ces modules non GUI soient un gros plus pour l'adoption de Qt ou pensez-vous au contraire qu'ils sont complètement marginaux et insignifiant en regard de la partie GUI ?

De même, que pensez-vous de l'impact des différents bindings de Qt ? Comme Jiyuu, je suis un amateur de Python (au même titre que Qt en fait) et le binding PyQt a été une de mes motivations à apprendre Python car je connaissais déjà Qt. On pourrait imaginer le cheminement inverse.