Bonsoir,

En lisant le post de Don_raptass, je me suis posé la question de choisir une bibliothèque graphique: Qt, GTKMM, wxWidgets, autres ?

Je n'ai encore rien développer comme GUI, et il faudra bien que je m'y mettes un jour. Aussi, j'ai regardé sur le forum: Il y a plusieurs comparaisons, mais pas de conclusions

J'ai regardé [trop] rapidement Qt, et j'ai trouvé qu'il était un peu trop "C++ old style", avec sa macro QOBJECT, ses new() et ses pointeurs nus, (enfin ce que j'essaie d'oublier, moi qui vient du C). Bien sûr, Qt ce n'est pas que la HMI, bien sûr il y a une doc sur-abondante, bien sûr il y a une très grosse communauté, Bien sûr, il y a Qt Designer ...

Mais, ...

J'ai regardé un peu (c'est à dire aussi rapidement) GTKMM. Ca m'a paru mieux respecter le C++ moderne: avec un namespace, avec le respect de la STL, avec des exceptions, meilleur gestion des "signaux", il y a "glade",  ... mais ce doit être moins portable Linux/MS Windows. (Pas encore réussi à compiler sous Windows ...)

La eReputation de wxWidgets est d'être un peu plus compliquée "pour entré dedans" que Qt. (Je n'ai pas encore regarder)

Je voudrais pas lever un troll, mais si vous avez des expériences/arguments, merci de m'aider à ne pas faire le mauvais choix 

(PS: En cherchant sur le forum, je suis tombé sur "nana", projet de lib graphique, compatible C++11. Vous connaissez ?)

Personnelement j'utilise la SFML mais c'est complexe a certains niveaux.

Parait QT est tres bien, en plus que c'est un constante evolution, la manipulation devient plus facile...

Bonjour,

Pour avoir testé Qt, sfml et un autre dont le nom débutait par un a(je m'en souviens plus)  je peut te conseiller de trouver ce qui suit tes aspirations personnelles et professionneles.

Qt est un poids lourd de l'industrie graphique, aussi utilisé dans l'embarquée ... C'est quasiment un langage à part entiere

Sfml donne un bon début pour les jeux vidéos ( compréhension de mécanismes basique)

Qt : c'est pas si vieux. Justement ils ont intégré beaucoup de choses du C++ modernes, comme les vrais objet de fonctions pour les QObject:connect (alors qu'avant ça marchait sur un système de chaine de caractère, et oui !). Bien que l'allocation soit plutôt manuelle, elle est intelligemment faite car elle fonctionne par hierarchie. Ainsi on ne désalloue pas manuellement un objet après l'autre mais simplement le plus grand parent. En général avec les UI de Qt Designer on ne fait même rien !

Gtk(MM) : Gtk est un peu plus minimaliste que Qt mais il a un énorme inconvénient, il est hyper orienté GNOME et Linux. Ainsi pour faire du portable il faut beaucoup configurer pour avoir un style natif (comme des variables d'environnement).

wxWidgets : Tu disais que Qt est old school mais c'est bien pire pour wxWidgets et sa conception est pas hyper élégante.

À l'heure actuelle il y a rien d'ultra moderne question toolkit. Mais boost::ui pourrait peut-être changer la donne. Note : il est basé sur wxWidgets.

-
Edité par markand 21 janvier 2020 à 8:59:14

Salut,

Si, par "bibliothèque graphique", tu comprends la capacité de créer des IHM avec des boutons, des checkboxes, des listes déroulantes et autres joyeusetés, il faut bien comprendre que toutes les bibliothèques qui existent actuellement (que ce soit Qt, WxWidget, GTKMM ou autres) souffrent du même problème: comme leur développement a débuté au plus tard au tout début du millénaire, elles souffrent énormément du poids de leur histoire, et elles vont donc toutes souffrir de ce que tu appelle "Old style".

Qt a l'énorme avantage de prévoir une nouvelle version majeure pour cette année (on va passer à Qt 6 :D)  et semble décidée à abandonner (ce n'est pas trop tôt) son système de build originel (QMake).  Avec un peu de chance, la macro Q_OBJECT va aussi disparaître, même si je fais sans doute preuve d'un peu trop d'optimise

Mais l'un dans l'autre, j'ai l'impression que Qt est la seule bibliothèque a avoir vraiment évolué au fil des nouvelles normes, à tel point qu'il est d'ailleurs prévus que la version 6 ne soit compatible qu'avec C++17 et ultérieures (peut-être même C++20, si elle est finalisée suffisamment tôt).

Je n'ai pas parlé de la SFML, qui a été développée sur base du C++11, car ce n'est pas à proprement parler une bibliothèque prévue pour faire de l'IHM.  Parfaite pour la création d'animations et autres joyeusetés graphiques du même style, mais clairement pas destinée à la création d'IHM

koala01 a écrit:

Je n'ai pas parlé de la SFML, qui a été développée sur base du C++11, car ce n'est pas à proprement parler une bibliothèque prévue pour faire de l'IHM.  Parfaite pour la création d'animations et autres joyeusetés graphiques du même style, mais clairement pas destinée à la création d'IHM

Mince...

Je profite de son topic, pour demander comment utiliser les bibliotheques qt dans code::blocks svp. J'utilise sfml et le temps d'actualistation de la fenetre est une seconde(un peu long pour moi). Qt doit surement etre mieux mais je veux pas utiliser un autre ide(qt creator).

Salut,

Qt est vraiment incontournable, ça m'embête un peu aussi de devoir suivre sa conception dans certains cas ( je me suis frotté à son model/view y'a pas si longtemps qui m'a donner du fil à retordre ) mais bon on s'y fait, et je vois plus ses défauts comme des points améliorables plutôt que rédhibitoires, car malgré tout, ça marche très bien et offre des fonctionnalités très avancées. Dans tout les cas je te conseille de t'y essayer, même si c'est pour en choisir une autre pour certains besoins particuliers plus tard

Je viens ajouter FLTK à ta liste
Parce que j'aime bien son API et sa philosophie, même si son rendu est pas des plus joli, et que sa gestion de projet et site web sont veilliot. Si elle arrive à évoluer et à se forger une communauté un peu plus conséquente, je pense que ça peut devenir une excellente option.

WxWidget j'ai pas du tout apprécier, l'utilisation intensive de macro ça me file des boutons.

Gtkmm m'a paru sympa aussi du peu que j'en ai vu, mais comme l'a dit markand l'aspect cross-platform est à améliorer

nana m'a l'air intéressante mais très expérimental encore, si tu cherches une lib pour acquérir des compétences en IHM, je te conseille de t'appuyer sur quelque chose de mature, tu pourras essayer nana une fois que tu auras un peu d'expérience (ou qu'elle sera bien plus stable)

Pour utiliser Qt avec C::B, je sais pas comment on fait, mais éventuellement tu peux le gérer avec CMake et te générer un fichier projet de C::B. Sinon la spécificité de Qt par rapport aux autres lib, c'est qu'il faut exécuter le MetaObjectCompiler et ajouter les sources générés à la compil, si t'arrives à ajouter cette étape dans la config C::B, après tu gères comme une bibliothèque normale et ça devrait aller.

Hello,

Pour ma part, en C++, je ne connais que Qt pour l'utiliser quotidiennement dans mon travail. Donc je ne pourrai pas parler des autres API existantes, ni même faire de comparaison.

Avec Qt, tu as aussi le QML. C'est une autre façon de faire une GUI. J'avais quelques a priori avant de l'utiliser mais depuis que j'ai dû faire des composants customs (impossibles à faire en widgets C++), je le trouve trop bien. J'ai vraiment pris mon pied, alors que je déteste le JavaScript.

Je lui trouve l'avantage de bien permettre un cloisonnement vue (QML) et modèle (C++).

Sans parler de la facilité à faire une UI moderne, les bindings pas du tout verbeux, etc. En gros, mettre côte à côte du code de GUI en C++ et QML, le QML est mille fois plus propre et lisible. Ça fait une différence notable pour la maintenance aussi.

Quant aux macros, elles sont avant tout là pour justement rendre le C++ bien plus facile et finalement plus "moderne", à mon sens. Le langage C++ est oldschool de par son âge et son historique, c'est un fait. Qt n'a donc pas d'autres façons que d'utiliser ce qui est à sa disposition pour rendre malgré tout le langage moins contraignant. Par exemple, la gestion des objets et de la mémoire à travers l'héritage de QObject.

Une autre macro hyper pratique mais qui peut rendre le code barbare, c'est à tout hasard Q_ENUM_NS. Avec elle, tu peux convertir une valeur numérique d'enum en string (j'entends là, son nom dans l'enum). A l'inverse, tu peux aussi avoir son nom sous forme de string et la reconvertir en valeur numérique. Le C++ vanilla ne peut pas faire ça alors que ça peut être très utile.

Au final, le choix de l'API pour faire sa GUI ne se limite pas qu'à certains aspects du code, et surtout pas uniquement le "visuel" du code, mais aussi aux fonctionnalités offertes à côté.

romantik a écrit:

Pour utiliser Qt avec C::B, je sais pas comment on fait, mais éventuellement tu peux le gérer avec CMake et te générer un fichier projet de C::B. Sinon la spécificité de Qt par rapport aux autres lib, c'est qu'il faut exécuter le MetaObjectCompiler et ajouter les sources générés à la compil, si t'arrives à ajouter cette étape dans la config C::B, après tu gères comme une bibliothèque normale et ça devrait aller.

koala01 a écrit:

Qt a l'énorme avantage de prévoir une nouvelle version majeure pour cette année (on va passer à Qt 6 :D)  et semble décidée à abandonner (ce n'est pas trop tôt) son système de build originel (QMake).  Avec un peu de chance, la macro Q_OBJECT va aussi disparaître, même si je fais sans doute preuve d'un peu trop d'optimise

Pour Q_OBJECT, c'est pas prévu avant Qt 8, d’après les dires de Lars a un dev summit. 

Pour cmake, ça fait longtemps qu'on peut l'utiliser avec Qt. La différence est que cmake devient l'outil de build par défaut.

Pour le C++20, probablement pas. Qt se base sur le support des compilateurs sur les différentes plateformes, pas sur la publication de la norme, pour adopter une norme mini.

Et merci pour touts vos réponses ! Je les ai lu et relu avant de vous répondre.

koala01 a écrit:

Si, par "bibliothèque graphique", tu comprends la capacité de créer des IHM avec des boutons, des checkboxes, des listes déroulantes et autres joyeusetés, il faut bien comprendre que toutes les bibliothèques qui existent actuellement (que ce soit Qt, WxWidget, GTKMM ou autres) souffrent du même problème: comme leur développement a débuté au plus tard au tout début du millénaire, elles souffrent énormément du poids de leur histoire, et elles vont donc toutes souffrir de ce que tu appelle "Old style".

Oui en effet, c'est bien de ce ca que je parle: Créer des HMI (ou IHM en français). Mais pour moi, même si cette bibliothèque est "vielle", écrite en C ou autre (Pascal comme borland), ce n'est pas un problème. Ce qui m'importait, c’était de l'interface  soit en C++ moderne (après C++11), avec des smart pointer, des exception si besoin, des gestion de "Call Back" avec detection des pb à la compilation, qu'importe s'il y a une glue d'adaptation, que ça passe par des bibliothèques native ou pas, ...

Asmitta a écrit:

Personnelement j'utilise la SFML mais c'est complexe a certains niveaux.

teri terance a écrit:

Sfml donne un bon début pour les jeux vidéos ( compréhension de mécanismes basique)

koala01 a écrit:

Je n'ai pas parlé de la SFML, qui a été développée sur base du C++11, car ce n'est pas à proprement parler une bibliothèque prévue pour faire de l'IHM.  Parfaite pour la création d'animations et autres joyeusetés graphiques du même style, mais clairement pas destinée à la création d'IHM

Donc, je ne pense pas que ce soit pour moi! (on va commencer simple, ...la 3D et l'annimation, on verra plus tard!)

J'ai regardé [trop] rapidement un exemple de WxWidget, et ma première impression confirme ce que vous me dites :

romantik a écrit:

WxWidget j'ai pas du tout apprécier, l'utilisation intensive de macro ça me file des boutons.

Moi aussi !

markand a écrit:

wxWidgets : Tu disais que Qt est old school mais c'est bien pire pour wxWidgets et sa conception est pas hyper élégante.

J'ai aussi regardé [toujours trop] rapidement FLTK (Merci Romantic) et Nana, ... J'ai pas trouvé beaucoup d'exemple, de tuto, ou autre ... Pour un débutant comme moi, c'est pas gagné !

Boost::ui, (Merci Markand), ça me parait encore plus expérimental !

Enfin, J'ai passé un peu de temps dans la journée pour essayer de compiler une appli GTKMM sur MS Windows, ... Et bien, c'est pas gagné ! Je sui donc d'accord avec vous :

markand a écrit:

Gtk(MM) : Gtk est un peu plus minimaliste que Qt mais il a un énorme inconvénient, il est hyper orienté GNOME et Linux. Ainsi pour faire du portable il faut beaucoup configurer pour avoir un style natif (comme des variables d'environnement).

romantik a écrit:

Gtkmm m'a paru sympa aussi du peu que j'en ai vu, mais comme l'a dit markand l'aspect cross-platform est à améliorer

Dommage, ça corresponder plus à ce que je cherchais ...

Il reste donc Qt, qui fait l'unanimité ...

teri terance a écrit:

Qt est un poids lourd de l'industrie graphique, aussi utilisé dans l'embarquée ... C'est quasiment un langage à part entiere

markand a écrit:

Qt : c'est pas si vieux. Justement ils ont intégré beaucoup de choses du C++ modernes, ...

koala01 a écrit:

Qt a l'énorme avantage de prévoir une nouvelle version majeure pour cette année (on va passer à Qt 6 :D)  ...

Mais l'un dans l'autre, j'ai l'impression que Qt est la seule bibliothèque a avoir vraiment évolué au fil des nouvelles normes, ...

romantik a écrit:

Qt est vraiment incontournable, ...

AntiXeon a écrit:

Pour ma part, en C++, je ne connais que Qt ...

En ce qui concerne QML, connait pas encore, pas encore d'idée ... A suivre.

Bon, j'ai pas beaucoup de choix ... GTKMM si je reste sur linux, Qt si je veux quelque chose de portable.

Merci pour vos réponses. Y'a plus qu'a faire!

Bien cordialement.

PS1) Je suis étonné que GbDivers n'ai pas argumenté en faveur de Qt. J'étais sûr qu'il le ferais ...

PS2)

Asmitta a écrit:

Je profite de son topic, pour demander comment utiliser les bibliotheques qt dans code::blocks ...

Ce ne serai pas plus simple d'utiliser SFML dans Qt Creator, plutôt que mettre les [[très] nombreuses] lib Qt dans C::B ? Je pense que tu cherches à te faire mal !

Dedeun a écrit:

PS1) Je suis étonné que GbDivers n'ai pas argumenté en faveur de Qt. J'étais sûr qu'il le ferais ...

Je n'ai pas grand chose a ajouter a ce qui a ete dit. Ca fait des annees que Qt est de facto la lib graphique du C++. A mon sens, si c'est pour un projet pro, Qt doit etre considere. Pour un debutant C++, apprendre Qt est un passage oblige (meme si c'est juste pour faire 2 boutons), tout comme il faut avoir essaye au moins une fois clang, gcc, cmake, visual studio, boost, etc.

Et j'appuie le message de AntiXeon sur le QML. (Achetez mon livre ! )

Dedeun a écrit:

Asmitta a écrit:

Je profite de son topic, pour demander comment utiliser les bibliotheques qt dans code::blocks ...

Ce ne serai pas plus simple d'utiliser SFML dans Qt Creator, plutôt que mettre les [[très] nombreuses] lib Qt dans C::B ? Je pense que tu cherches à te faire mal !

Bonsoir,

J'avais laissé le post "non résolu", en me disant "Il va bien avoir une personne qui va avoir une autre idée, bonne ou mauvaise, farfelu ou pas, ... mais quoi, une autre idée, du nouveau, de inédit, du merveilleux, de l'extraordinaire !".

Et bien Non! Rien! Nada! No thing !

J'en déduit "Hors de Qt, pas de salut !". Bon pas le choix, il faut que je m'y mette. A moi les Qtruc, les Qbasards, les QjeNeSaitPasQuoi, ... on doit s'y faire.

Merci encore pour vos réponses.

Tu n'es pas obligé de tout préfixer avec Q. Une solution simple :

#define Object QObject
#define Widget QWidget

et comme ca, plus de "Qtruc, les Qbasards, les QjeNeSaitPasQuoi, ..." dans ton code !

Dedeun a écrit:

Bonsoir,

J'avais laissé le post "non résolu", en me disant "Il va bien avoir une personne qui va avoir une autre idée, bonne ou mauvaise, farfelu ou pas, ... mais quoi, une autre idée, du nouveau, de inédit, du merveilleux, de l'extraordinaire !".

Et bien Non! Rien! Nada! No thing !

J'en déduit "Hors de Qt, pas de salut !". Bon pas le choix, il faut que je m'y mette. A moi les Qtruc, les Qbasards, les QjeNeSaitPasQuoi, ... on doit s'y faire.

Merci encore pour vos réponses.

T'es sacrement drôle.

Qt est le plus conseillez donc vas y, tu peux toujours venir souffrir sur la SFML avec moi sinon

C'est pas prévu dans Qt6. Et je crois que je n'ai jamais entendu que c'était dans les discussions. Donc a mon avis, jamais.

Par contre, Qt propose deja la gestion des namespaces. Par contre, il faut recompiler Qt en spécifiant le namespace que tu veux utiliser.

gbdivers a écrit:

Tu n'es pas obligé de tout préfixer avec Q. Une solution simple :

#define Object QObject
#define Widget QWidget

et comme ca, plus de "Qtruc, les Qbasards, les QjeNeSaitPasQuoi, ..." dans ton code !

Ah ! horreur ! Des macros ! Et en minuscule en plus ! 

romantik a écrit:

.. l'utilisation intensive de macro ça me file des boutons.

Moi aussi !

markand a écrit:

J'avoue espérer qu'ils utilisent les namespaces par défaut et retirer le préfixe Q pour une version majeure à venir. Ça commence à faire vieux.

Pour ma part, ce n'est pas le préfix en Q qui me pose problème, ... Non c'est qu'il faut ré-apprendre de nouvelles classes, proche de cette de la lib standard, (Je pense que comme la lib standard, ça à pour origine Boost de 1995, donc c'est proche), mais ... pas exactement pareille! Déjà que en tant que vieux c'est difficile à si mettre, mais en plus il y en a deux à apprendre, ... et à confondre!

Bien cordialement,

PS: Merci Asmitta d'avoir remarqué:

Asmitta a écrit:

T'es sacrement drôle.

Mais, il ne faut pas exagérer, ce ne sont que quelques blagues à 5 balles. Mais je suis d'accord, la vie est trop triste!

Dedeun a écrit:

Non c'est qu'il faut ré-apprendre de nouvelles classes, proche de cette de la lib standard, (Je pense que comme la lib standard, ça à pour origine Boost de 1995, donc c'est proche), mais ... pas exactement pareille! Déjà que en tant que vieux c'est difficile à si mettre, mais en plus il y en a deux à apprendre, ... et à confondre!

Globalement, Qt recommande d'utiliser les classes de la STL (std::vector, std:unique_ptr, etc), pas les classes de Qt. (Exception pour QString et pour QList dans des cas spécifiques).

Et en soi, bof comme argument, de mon point de vue. Apprendre Qt, c'est apprendre des centaines de nouvelles classes et idiomes. Les doublons avec la STL, c'est moins d'une dizaine de classes. Je n'ai jamais ressenti cette confusion dont tu parles.

Dedeun a écrit:

 Non c'est qu'il faut ré-apprendre de nouvelles classes, proche de cette de la lib standard, (Je pense que comme la lib standard, ça à pour origine Boost de 1995, donc c'est proche),

Hé ben non, justement...

D'abord parce que la bibliothèque standard n'a commencé à s'inspirer de boost que pour les fonctionnalités apparues en C++11 (unique_ptr, shared_ptr, threads, et autres joyeusetés)

Ensuite parce que le développement de Qt a commencé déjà bien avant la standardisation de 1995 (aux alentours de 1990, il me semble).

Après, il y a clairement eu des inspirations des deux cotés

Cependant, QMap, pour ne donner qu'un exemple bien particulier, n'est pas tout à fait compatible avec std::map, ne serait-ce que parce qu'il est impossible de définir le comparateur qui permet de définir l'ordre de tri avec QMap

Je m'en suis rendu compte alors que l'on en était encore à Qt-4 et j'ai proposé de corriger le tir.  A l'époque, la proposition a été refusée parce que cela aurait cassé la compatibilité binaire entre les version de Qt-4.x.  Et la proposition a été oubliée lors du passage à Qt-5.  je l'ai remise sur le tapis lorsque j'ai appris qu'ils envisageait de développer Qt-6

Bonsoir et merci pour ces nouvelles réponses, ... qui bien sûr sont sources de nouvelles questions 

gbdivers a écrit:

Globalement, Qt recommande d'utiliser les classes de la STL (std::vector, std:unique_ptr, etc), pas les classes de Qt. (Exception pour QString et pour QList dans des cas spécifiques).

Dans le prototype d'une fonction d'une class Qt, pour un argument ou une valeur de retour, tu as un type QString, il va bien falloir que tu passes/reçoives un QString et pas un std::string. Non ? Ou alors tu fais un cast ? (en mémoire ça doit beaucoup se ressembler. Non ?) Comment tu peux utiliser un std::string, si le prototype te demande un QString ? Ou alors il faut recopier ta std::string dans une variable temporaire QString juste avant l'appel ?

gbdivers a écrit:

Les doublons avec la STL, c'est moins d'une dizaine de classes. Je n'ai jamais ressenti cette confusion dont tu parles.

Je pensais qu'il y en avait plus ... mais je ne me fais pas confiance, je suis un vieux, moi.

Merci pour ta réponse Koala01, mais (à l'exception de la date, où j'ai assurément faut) on est à peu près d'accord, non ?

Je vous promets que c'est la dernière fois que je réponds à ce post, avant d'avoir fait ma première fenêtre Qt. Si non ça va commencer à ressemblé à un troll, ... ce que je ne voulez pas!

Bien cordialement

Dedeun a écrit:

Dans le prototype d'une fonction d'une class Qt, pour un argument ou une valeur de retour, tu as un type QString, il va bien falloir que tu passes/reçoives un QString et pas un std::string. Non ? Ou alors tu fais un cast ? (en mémoire ça doit beaucoup se ressembler. Non ?) Comment tu peux utiliser un std::string, si le prototype te demande un QString ? Ou alors il faut recopier ta std::string dans une variable temporaire QString juste avant l'appel ?

QString est justement une exception, du fait que std::string gere mal l'unicode. Avec un projet Qt, il est plus simple de tout faire avec QString plutôt que passer son temps a faire des conversions.

Et non, en memoire, c'est pas du tout pareil. std::string utilise des char (8b) alors que QString utilise l'UTF16 (16b).

Dedeun a écrit:

Si non ça va commencer à ressemblé à un troll, ... ce que je ne voulez pas!

C'est pas troll, tes questions sont legitimes.

Salut, je me permet de déterrer ce sujet un peu vieillot pour apporter une bibliothèque cross-plateform à la liste. Qui plus est, elle est très moderne et assez complète !

Je nomme Avalonia.net  qui comme son nom l'indique, fonctionne avec le DotnetCore (XAML + C#). En espérant pouvoir aider ceux qui passeront par se sujet.

Marty MacFLy a écrit:

Salut, je me permet de déterrer ce sujet un peu vieillot pour apporter une bibliothèque cross-plateform à la liste. Qui plus est, elle est très moderne et assez complète !

Je nomme Avalonia.net  qui comme son nom l'indique, fonctionne avec le DotnetCore (XAML + C#). En espérant pouvoir aider ceux qui passeront par se sujet.

Salut,

Tu nous expliqueras pourquoi tu la postes sur un forum de C++.

Bonjour Marty,

En effet, c'est un peu déterrage, ... et un peu curieux de me proposer une lib C#, à la fin de cette discussion sur le forum C++. C'est compatible ? Il y a une glu entre les deux ? Elle apporte quoi cette lib ?

Cordialement.

PS: Tient, je me m'y suis toujours pas mis à QT. Je n'ai pas beaucoup avancé cette année 2020 !