Discussion :

[screetch]

Je ne suis complétement d'accord. je m'explique :
Ce n'est pas par ce qu'on utilise QT pour le coeur d'une bibliothèque ou d'un programme qu'on le lie à une interface graphique.

GTK a grosso modo les mêmes fonctionnalités. Si tu utilises des Qlist pour ton mesh d'un seul coup l'interface graphique devient "forcément" en Qt, et tu te prives de la possibilité d'utiliser GTK. Or, rien ne me dit qu'un mesh doive utiliser une interface Qt pour etre édité. C'est pour moi le contraire de ce que tu as dit : utiliser des Qlist dans une bibliothèque bas niveau c'est conduire un autre développeur a utiliser Qt sur une bibliothèque haut niveau.

[Invité]

GTK a grosso modo les mêmes fonctionnalités.

Tous les framework d'interface, en fait... Tous ceux que je connais (perso j'utilise Borland, je regarde Qt de loin) ont tendance à se vouloir des "sur langage" du C++. Avec, on peut développer presque sans connaitre le C++, quasiment tout est déjà mâché, et ça gagne beaucoup de temps.

Sur de petits projets (disons destinés à durer deux ou trois ans) avec beaucoup d'IHM, et peu de valeur ajoutée métier (genre la couche métier c'est une base de données qu'on requête, et le soft présente les résultats et cache les détails du SQL), c'est la bonne solution. Il faut prendre le framework que le dev principal connait, et exiger des autres qu'ils le connaissent ou l'apprennent... Au total, ce sont plus des projets en Qt que des projets en C++, mais ce n'est pas un problème, ca va marcher, ca va se développer vite, c'est parfait.

Sur des projets avec beaucoup de C++ et très peu d'IHM, le framework doit être aussi minimisé que possible. Là le tout Qt (ou n'importe quel autre framework) est une aberration. On écrit un moteur en C++, et on branche ca sur une interface. Si l'interface est en Qt, il faut essayer d'éviter tout les Qt-isme qui peuvent l'être.

La vraie difficulté, c'est la situation intermédiaire: une IHM importante, et pas mal de calcul métier, dans une appli qui doit durer une dizaine d'années et au delà. A mon avis, une parfaite isolation IHM-moteur est à peu près impossible. Tout ou tard, la jolie frontière qu'on a bâtie entre les deux deviendra poreuse et floue. L'argument de la vitesse (des "fonctions Q" vs la STL) ne me parait pas recevable: en général, en sachant bien utiliser l'un ou l'autre on arrive toujours à compenser). Pour moi, le choix du tout framework présente un avantage : il limite le nombre de librairies que les developpeurs (présents ou futurs) doivent maîtriser. Si on n'a que Qt, alors on n'a plus besoin d'apprendre boost, les détails de la STL (la grande majorité des devs connaissent mal la STL), etc... Le revers de la médaille, c'est que si dans 5 ans, Qt passe de mode (ca arrivera forcément), il sera plus difficile d'interesser les nouveaux recrutés à cette "techno du passé".

Du coup, etre tout Qt, ca signifie dépendre pas mal des spécialistes Qt de son entreprise. Mais c'est vrai de tout framework.

Le seul intérêt de conserver un peu de "non framework" dans le projet, c'est si on décide un jour d'en utiliser un autre, pour un autre projet, par exemple. Si tu veux lancer un projet GTK, tout ton joli code Qt est inutilisable. Les parties STL le seront...

Vis à vis de Borland (mon framework), ma stratégie est la suivante
- toujours aller dans le sens du framework (lutter contre, c'est idiot)
- là ou une solution équivalente mais standard existe (STL ou autre) toujours la préférer à la solution Borland
- sauf si cette solution est plus complexe à implémenter, et à débugger

Sur la critique de screetch, je suis assez d'accord que les applis "héritent" du framework qu'elles utilisent, mais je ne crois pas qu'il soit possible de faire autrement... Tenter l'inverse, c'est souvent "lutter contre" le framework, et passer son temps à se battre contre les outils qui sont censés nous simplifier la vie.

Francois

[yan]

GTK a grosso modo les mêmes fonctionnalités. Si tu utilises des Qlist pour ton mesh d'un seul coup l'interface graphique devient "forcément" en Qt, et tu te prives de la possibilité d'utiliser GTK.

Qt est découpé en module (et dll au maximum indépendante). Tu peut sans trop problème utiliser le core, le network, le xml ou la partie sgbd sans la partie ihm. Et faire ton ihm avec gtk ou autre. Tout comme tu peut utiliser glib sans gtk+.
De plus y as des travaux pour les rendre compatible
http://gitorious.org/gqt

C'est pour cela que Qt est soit
* QCoreApplication : appli sans ihm
* QApplication : appli avec ihm.

Pour faire un équivalent avec GTK :
QtCore <=> Glib
QtGui <=> GTK+

Or, rien ne me dit qu'un mesh doive utiliser une interface Qt pour etre édité. C'est pour moi le contraire de ce que tu as dit : utiliser des Qlist dans une bibliothèque bas niveau c'est conduire un autre développeur a utiliser Qt sur une bibliothèque haut niveau.

Pour moi c'est un choix technologique. Faut savoir faire le pour et le contre.

mais, a force de voir en Qt la solution idéale on a tendance a prendre Qt comme l'outil qui résout tout (ce qui est un enorme défaut)

et je dirai de plus que la plupart des gens de ce forum font de même en pensant que chaque problème (a tort) est résolu par du code C++. Ca peut être vrai mais c'est pas le plus performant. (je suis le premier a tomber dans cette catégorie, en toute honnêteté. c'est un problème tout a fait humain. s'en tirer relève du vrai génie et si tu y arrives, alors bravo )

mais je suis tous à fait d'accord avec ceci, Qt n'est pas LA solution. S'en est une parmi d'autre et pas pour tous.
Je pense que l'on as tendance à vouloir utiliser ce que l'on maitrise le plus. Mais faut être ouvert technologiquement. Dernièrement je devais faire un petit server rest locale. Me disant que c'est simple, j'ai commencé en Qt. Et après une journée et vue à quel point faut réinventé la roue,j'ai laissé tombé pour du C#.
Et la en moins de 20 lignes j'avais mon server 1000x plus puissant que ce que j'avais fait et sans prise de tête. Et je n'ai rien regrette. Surtout quand j'ai du exploiter en plus des objets COM ou tout est grandement simplifié en .Net.

[yan]

Tous les framework d'interface, en fait... Tous ceux que je connais (perso j'utilise Borland, je regarde Qt de loin) ont tendance à se vouloir des "sur langage" du C++. Avec, on peut développer presque sans connaitre le C++, quasiment tout est déjà mâché, et ça gagne beaucoup de temps.

Qt c'est du C++, sinon il ne supporterai pas autant de compilateur; Borland c'est surtout un compilateur C++ avec son framework.
(enfin il me semble)

Si on n'a que Qt, alors on n'a plus besoin d'apprendre boost, les détails de la STL (la grande majorité des devs connaissent mal la STL), etc...

Ça c'est une remarque faite à Qt que j'arrive pas à comprendre. En quoi faire du Qt t'empêche d'utiliser boost ou autre? A chaque fois j'ai l'impression que les gens pensent que Qt est un langage... c'est du C++, ce que génère moc et uic c'est du C++(que tu n'as pas envie et l'intérêt de l'écrie à la main). Ce qui compile ton code est un compilateur C++. Rien n'oblige de l'utiliser partout. Sur un projet, j'ai utiliser Qt pour xpath, boost pour ses quaternions, matrices et smart_ptr et la stl pour le reste.
Je n'ai pas eu de problème.

Le seul intérêt de conserver un peu de "non framework" dans le projet, c'est si on décide un jour d'en utiliser un autre, pour un autre projet, par exemple. Si tu veux lancer un projet GTK, tout ton joli code Qt est inutilisable. Les parties STL le seront...

C'est la même chose pour toute lib (boost, poco, ...). C'est un points qu'il faut prendre en compte. Si on veut la changer cela aura un coup.

Je trouve qu'il est de bonne pratique de faire (quand c'est pertinent) ses propres classes pour interfacer la lib et ainsi pouvoir en utiliser une autre si besoin. Bon d'accord avec des framework type Qt c'est pas toujours possible.

[Invité]

Qt c'est du C++, sinon il ne supporterai pas autant de compilateur; Borland c'est surtout un compilateur C++ avec son framework.

En fait, le framework Borland c'est du Delphi, mais qui s'interface, via l'EDI et le compilateur, avec du C++.

Mais dans un cas comme dans l'autre, on peut utiliser les composants de haut niveau comme une sorte de "sur langage", c'est à dire qu'on assemble des briques assez grosses, sans presque jamais faire de C++.

Le C++ de base, c'est un peu du mecano, t'as des barres, des écrous, des boulons, un moteur. Les frameworks, c'est plutot des legos technic, avec des grosses pieces spécialement formées pour les besoins de la cause.

Ça c'est une remarque faite à Qt que j'arrive pas à comprendre. En quoi faire du Qt t'empêche d'utiliser boost ou autre? A chaque fois j'ai l'impression que les gens pensent que Qt est un langage...

Rien n'empêche de le faire, sauf le temps disponible. En général, sur un projet, tu es toujours en délais contraints, donc tu vas au plus vite. Par ailleurs, il vaut mieux bien maitriser une librairie que d'en connaitre vaguement 5. Et on parle là de choses (Boost, Qt) qui évoluent assez vite. La question se pose donc, quand tu décides de te former, de savoir s'il vaut mieux approfondir le framework que tu utilises, ou essayer d'en apprendre un autre au cas où (ou te former sur un bout de boost que tu ne connais pas)...

Si tu travailles avec une équipe, la dernière chose que tu veux, c'est que tes développeurs passent la moitié de leur temps à lire des manuels, pour se faire une culture générale ou se mettre à jour sur une demi douzaine de technologies. (Je te garantis que la majorité ne le fera pas sur son temps libre...)

Tu ne veux pas non plus que chacun écrive dans son jargon, parce que le code va vite devenir inmaintenable, et que les petites incompatibilités entre librairies vont faire perdre un temps fou (ne serait ce qu'en palabres sur qui a la meilleure...)

Au total, tu peux bien sur tout utiliser, Qt, GTK+, Boost, et d'autres, mais sur un projet, tu préfères souvent avoir un petit nombre d'outils communs, que tout le monde maitrise, avec parfois un ou deux spécialistes qui gèrent les cas tordus. Tu te retrouves avec un code plus maintenable, moins dépendant de ceux qui l'ont écrit, et souvent plus concis.

Et du coup, quand tu as un framework qui te propose pas mal de choses, la question de se limiter à ce seul framework est assez légitime, enfin je crois.

Je trouve qu'il est de bonne pratique de faire (quand c'est pertinent) ses propres classes pour interfacer la lib et ainsi pouvoir en utiliser une autre si besoin. Bon d'accord avec des framework type Qt c'est pas toujours possible.

Avec les framework d'IHM, je doute que ce soit jamais possible... Avec d'autres libs ca l'est parfois, mais d'expérience, on écrit souvent ces classes d'interface, en se disant "comme ca on pourra", et le jour ou on doit le faire, ben on se rend compte qu'on avait oublié des choses, forcément parce qu'on ne connaissait qu'une lib, et pas la "nouvelle" qui ne marche justement pas avec la classe, etc...

Francois

[yan]

Rien n'empêche de le faire, sauf le temps disponible. En général, sur un projet, tu es toujours en délais contraints, donc tu vas au plus vite. Par ailleurs, il vaut mieux bien maitriser une librairie que d'en connaitre vaguement 5. Et on parle là de choses (Boost, Qt) qui évoluent assez vite. La question se pose donc, quand tu décides de te former, de savoir s'il vaut mieux approfondir le framework que tu utilises, ou essayer d'en apprendre un autre au cas où (ou te former sur un bout de boost que tu ne connais pas)...

Si tu travailles avec une équipe, la dernière chose que tu veux, c'est que tes développeurs passent la moitié de leur temps à lire des manuels, pour se faire une culture générale ou se mettre à jour sur une demi douzaine de technologies. (Je te garantis que la majorité ne le fera pas sur son temps libre...)

Tu ne veux pas non plus que chacun écrive dans son jargon, parce que le code va vite devenir inmaintenable, et que les petites incompatibilités entre librairies vont faire perdre un temps fou (ne serait ce qu'en palabres sur qui a la meilleure...)

Au total, tu peux bien sur tout utiliser, Qt, GTK+, Boost, et d'autres, mais sur un projet, tu préfères souvent avoir un petit nombre d'outils communs, que tout le monde maitrise, avec parfois un ou deux spécialistes qui gèrent les cas tordus. Tu te retrouves avec un code plus maintenable, moins dépendant de ceux qui l'ont écrit, et souvent plus concis.

Et du coup, quand tu as un framework qui te propose pas mal de choses, la question de se limiter à ce seul framework est assez légitime, enfin je crois.

je trouve que tu viens de donner une des meilleur réponse au débat.