Discussion :

[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.

[Jiyuu]

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 ?

En ce qui me concerne c'est LA raison pour laquelle j'utilise Qt avec Python. La puissance de Qt avec la facilité de Python c'est juste du bonheur. Mais il pourrait y avoir encore plus puissant et plus simple... Ouufff Qt Quick arrive. Il lui manque encore quelques outils (pilotes des principaux SGDB, écrirture et/ou lecture XML, ODF, PDF, ...).
Et pour être proche de la perfection, il faudrait que son utilisation "standalone" soit optimisée.
Je rassure les amateurs de C++ et Python, pour moi il faut aussi que Qt Quick reste compatible avec ces langages pour des gros projets.

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.

Un peu comme ça : http://pyotherside.readthedocs.org/en/latest/ ... en cours d'étude pour en percevoir la réelle utilité en particulier si on peut facilement rendre une appli 100% QML "standalone".

[charlespf]

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 ?

Pour ma part, que ce soit sur des projets personnels ou professionnels, l'utilisation des modules non GUI de Qt a toujours été un gain de temps dans le développement d'applications (utilisation d'une BDD, utilisation du réseau, exécution de processus externes, gestion de XML). Ce sont des modules éprouvés, ceux-ci utilisent également le principe des signaux/slots pour les traitements asynchrones.

Après je suis d'accord avec jiyuu, Qt doit rester compatible avec C++ et Python. Mais il me semble que QtQuick/Qml sont des modules Qt (DLL présentes dans le répertoire bin) et nécessite un lancement en C++ ou Python pour pouvoir démarrer.

[chrtophe]

J'avais commencé à travailler sur GTK, j'ai été assez vite limité et suis passé sur Qt.

Du coup, j'ai du me mettre au C++ ( je ne suis pas programmeur de métier ).

GTK ( GTK=Gimp ToolKit ), ça sert qu'à l'interface graphique, Qt il y a plein de sous-modules.

Je reviendrais pas en arrière.

Les portages PyQt et Qml permettent de faire un développement très vite et sans de grosses connaissances.

En framework, honétement je vois pas mieux.

[Jiyuu]

Après je suis d'accord avec jiyuu, Qt doit rester compatible avec C++ et Python. Mais il me semble que QtQuick/Qml sont des modules Qt (DLL présentes dans le répertoire bin) et nécessite un lancement en C++ ou Python pour pouvoir démarrer.

Pour repréciser un peu mes précédentes remarques, pour moi l'idéal serait :

• de pouvoir créer des applications complexes en utilisant QML associé à C++ ou Python euuhh ... ... ... oui ce que l'on peut faire actuellement en fait ;
• créer des applications simples sans être obligé d'utiliser C++ ou Python pour les exécuter, ce qui reviendrai à distribuer uniquement le code QML et qmlscene. Reste à savoir comment qmlscene peut-être "distribué" sans embarqué trop de choses à coté.

Exemple : un client mail pourraient être créer graphiquement en QML, mais tout le code pour le faire fonctionner exigera sûrement du code Python ou C++. À contrario, pour une calculatrice simpliste le code peut être fait à 100% en QML. Je trouve alors dommage "d'alourdir" l'application avec une couche C++ ou Python uniquement pour le lancer.

Qu'en pensez-vous ?

[charlespf]

Je suis d'accord avec vous. Après chacun aura ses affinités avec les environnements.
J'ai surtout l'impression qu'on nous impose à utiliser QtQuick/QML pour faire du développement d'applications graphiques. Le jour où l'on m'imposera cela, je commencerais à regarder une autre framework.

[loupium]

J'ai surtout l'impression qu'on nous impose à utiliser QtQuick/QML

Ce n'est qu'une impression probablement due à l'exposition de Qt Quick. Normal, les news portent plus souvent sur les nouveautés que sur la maturité.

[Jiyuu]

Je confirme : ce n'est qu'une impression.
Maintenant je trouve qu'une GUI est bien plus rapide à écrire en QML qu'en pur Qt. Pour cette raison je pense que de plus en plus de GUI seront faites en QML.

Mais rien n'empêche le programmeur d'utiliser du pur Qt ... S'il a envie de se compliquer la vie après tout

[Bktero]

Il y a t-il des différences de performances entre QML et C++ pour la création de la GUI ? Je présume qu'il faut démarrer une sorte de moteur avec QML alors qu'avec C++, c'est directement exécutable. Si je pense que cela est mineur pour de nombreuses appli, cela doit faire une différence pour d'autres (jeux un peu évolués, applications de sons,...).

[Jiyuu]

Personnellement je ne pense pas. Mais n'ayant pas fait de tests il m'est difficile d'avoir une position ferme. Il faut savoir par contre que QML est un langage interprété ... Cela peut-il jouer sur la GUI ???

En tout cas si ceci est avéré je pense que ça ne durera pas. Qu'est ce qui me fait dire ça ?
Deux choses, la première c'est que beaucoup de news concernant les nouvelles versions de Qt traitent du travail fait sur la partie Qt Quick et les termes "performances", "amélioraton moteur de rendu", etc sont souvent utilisés. Je pense donc que beaucoup d'efforts sont faits pour rendre QML très performant.

La deuxième concerne le monde pour lequel Qt Quick a été développé : le monde du mobile. Je ne suis pas assez calé en développement C++ et encore moins en développement mobile, mais pour moi si Qt Quick a été mis au point c'est pas pour avoir un truc qui marche moins bien.

Je ne sais pas si le développement d'appli mobile (pour rappel il est question des GUI ici) en pur Qt est faisable, mais une chose est sûre si Qt Quick existe c'est bien parce qu'il y avait une ou plusieurs difficultés de faire les GUI en C++.

Non ?

++

J

[Pierre GIRARD]

Tant que des projets comme Gnome et Xfce continuent sous GTK, il n'y aura pas de vague d'adoption pour Qt ...

Je vais me permettre quelques questions naïves suite à cette réponse.

J'ai toujours utilisé des applications GTK aussi bien que Qt. Et cela aussi bien sous KDE que sous LXDE et XFCE. Et donc :
- Quel est le problème à utiliser des applications GTK sous KDE ?
- Quel est le problème à utiliser des applications Qt sous GNOME ?
- Et enfin, quel est l'avantage de Qt sur GTK sous Windows ? sachant que les applications OpenSource que j'utilise sous Windows sont GIMP, OpenOffice et Mozilla ... et qu'aucune ne me pose de problème particulier sous Windows.

Ce qui me semble probable, c'est qu'il y a des applications qui a mon avis ne passeront pas sous Qt. Par exemple GIMP.

[Jiyuu]

Très sincèrement je pense qu'il n'y a aucun problème, c'est juste une question de rationalisation et de "surcharge" de ton PC. Par exemple si tu utilises KDE, il semble plus logique d'utiliser des applications basées sur Qt quand cela est possible plutôt que de réinstaller d'autres :

• tu peux espérer avoir déjà certaines dépendances d'installé pour d'autre programmes ;
• compatiblité des programmes entre eux ;
• ...

Je pense aussi qu'il y avait un autre point important : l'esthétique. En effet, et en ce qui concerne les applis GTK sous KDE, je me souviens que celles-ci n'étaient pas très belle alors que sous GNOME elles l'étaient.
Aujourd'hui ceci n'est majoritairement plus vrai, enfin sous KDE car il me semble qu'il existe paquet "gtkAsKde".

Pour l'utilisation d'appli Qt ou GTK sous windob alors là ... ... aucune idée. Je pense que d'un point de vue programmeur il s'agit surtout d'habitude. Je ne connais franchement pas GTK alors que je commence tout juste à maitriser Qt : donc je code en Qt.
D'un point de vue utilisateur, le lambda va surtout choisir le programme en fonction de ce qu'il cherche... qu'il soit fait en GTK ou en Qt ne lui importe peu je pense. Pour l'utilisateur-programmeur amateur comme moi, si j'ai le choix je prendrai du Qt, juste par chauvisme ...

Pour GIMP à coup sûr tu ne le trouveras jamais en Qt, mais un QIMP peut-être

[pvincent]

le passage à Qt 5 (surtout la suppression de la crainte que les dev avaient quand Qt 3 est passé à Qt 4) :

Moi, je suis pour la biodiversité et je trouve utile d'avoir le choix dans plusieurs toolkits.
Cela diminue le nombre de sueurs froides dont il est question plus haut.

Certains semble ignorer que GTK propose tout une série d'interfaces, dont une en C++ et une autre pour Python.
Le C n'est indispensable que si vous voulez créer vos propres widgets.

Je trouve qu'en ce moment GTK a pour faiblesses principales.
* les incompatibilités qui rendent le passage de GTK-2 à GTK-3 assez douloureux
* une documentation difficile à utiliser pour le débutant,
* être moins complet que Qt.

Pour le pb de MAC OS X, il faut rendre hommage à Andreas Fink http://pdb.finkproject.org qui compile pour cet OS un grand nombre de logiciels, GTK ou pas.

L'indépendance n'existe que par la connaissance et la diversité.

[imikado]

Je vais me permettre quelques questions naïves suite à cette réponse.

J'ai toujours utilisé des applications GTK aussi bien que Qt. Et cela aussi bien sous KDE que sous LXDE et XFCE. Et donc :
- Quel est le problème à utiliser des applications GTK sous KDE ?
- Quel est le problème à utiliser des applications Qt sous GNOME ?
- Et enfin, quel est l'avantage de Qt sur GTK sous Windows ? sachant que les applications OpenSource que j'utilise sous Windows sont GIMP, OpenOffice et Mozilla ... et qu'aucune ne me pose de problème particulier sous Windows.

Ce qui me semble probable, c'est qu'il y a des applications qui a mon avis ne passeront pas sous Qt. Par exemple GIMP.

Jyiuu a déjà bien répondu à ma place
Ce que j'avais en tête c'est surtout la mémoire: pour utiliser une application on charge en mémoire les librairies graphiques

Si on lance un environnement de bureau utilisant gtk ou Qt, il vaut mieux continuer (autant que faire se peut) utiliser des applications utilisant les mêmes

Après, effectivement Gimp utilise Gtk (dont il est à l'origine), mais certains lui préfère Krita quand ils evoluent en KDE

[Pierre GIRARD]

...Après, effectivement Gimp utilise Gtk (dont il est à l'origine)...

Je sais, c'est bien pour ça que je doute de voir un jour Gimp passer à Qt. Je ne connais pas Krita, mais je vais l'essayer

Cela étant, pour un non programmeur, et à par quand une application se nomme K... ou G... (et encore, Gwenview est me semble-t-il Qt et pas GTK), comment savoir si c'est une application Qt ou GTK ou autre...? Par exemple, Mozilla, Open/LibreOffice, Sane/XSane, Scribus, Apache, Lazarus, VLC, Wine, FileZilla, Opera ... et bien d'autres.

Et pour ce qui est des performances, même en chargeant à mort Linux avec des applications GTK sur un environnement Qt, je n'ai jamais réussit aussi bien à plomber les performances qu'avec Windows et des applications purement Windows.

Cela étant, merci pour ces réponses.

[imikado]

Oui c'est une habitude prise depuis que j'ai commencé à utiliser GNU/Linux (mandrake à l'époque) après avec la RAM qu'on a aujourd'hui, à part en machine virtuelle, on peut oublier cette recommandation.
Si ce n'est pour économiser l'espace disque des librairires et autres dépendances

[Jiyuu]

Lorsque je parlais de surcharge PC je parlais bien d'espace disque. Concernant les performances, c'est sûr qu'un Windob en 2 mises à jour il est déjà totalement à la ramasse. C'est d'ailleurs marant ça : chez la fenêtre mise à jour = pertes de performances () chez le pinguin = gain de performance (en général ) )... moi je dis : y en a qui n'ont pas bien compris l'utilité des MAJ

En ce qui concerne la question : comment savoir si une appli est du Qt ou du GTK je vois 4 possibilités :

• tu passes un coup de fil au développeur et tu lui demandes ;
• le développeur le précise sur son site ou tout autre communiqué ;
• tu regardes dans le "À propos de" s'il y a l'indication ;
• tu regardes les sources.

Bon la quatrième tu oublies sous windob...

[arnolddumas]

En ce qui concerne la question : comment savoir si une appli est du Qt ou du GTK je vois 4 possibilités :

• tu passes un coup de fil au développeur et tu lui demandes ;
• le développeur le précise sur son site ou tout autre communiqué ;
• tu regardes dans le "À propos de" s'il y a l'indication ;
• tu regardes les sources.

Bon la quatrième tu oublies sous windob...

Sinon un coup de ldd ou de dependancy walker ça marche aussi.

[Jiyuu]

Sinon un coup de ldd ou de dependancy walker ça marche aussi.

Bien vu le ldd... l'avais oublié lui.