tanguy_k a écrit :



…







Tu confonds les couches informatiques: le giga-ultra-kludge est l’implémentation du c++, c’est le niveau en dessous. Il est évident qu’au delà de ça, il est en général ré-utilisé des composants logiciels spécialisés. Dans le monde open source, aujourd’hui tu as souvent plusieurs composants qui remplissent la même fonction à peu près: tu as le choix. De plus, si la modularité est élevée, et que les coûts techniques des différents composants sont pas trop élevés, les coûts de sortie restent raisonnables. C’est ce que nous apporte le retour d’expérience des 40 ans de la philosophie unix.



" />

tanguy_k a écrit :



Peut etre, mais c’est pas pour ca qu’il faut jeter le bebe avec l’eau du bain.









Avec toutes les raisons que j’ai évoquées, et re-évoquées, si justement.



" />

Rozgann a écrit :



Comme dit de nombreuses fois au fil des commentaires, ce n’est pas comparable. Déjà, GTK+ et EFL sont des bibliothèques permettant de faire des interfaces graphiques à base de widgets, alors que Qt est un framework complet qui couvre beaucoup de choses, dont les interfaces, avec la possibilité d’utiliser des composants (QWidget) ou des interfaces déclaratives (QtQuick/QML).



Ensuite, ils ne sont pas aussi multiplateforme. EFL ne fonctionne que sur un dérivé Unix, GTK+ ne fonctionne que sous Unix/Windows/MacOS X. Voir le dernier paragraphe de l’article pour les systèmes supportés par Qt. Pour une application mobile multiplateforme, Qt a un train d’avance sur les alternatives que tu cites.







Perso, je ne parlais que de la partie toolkit gfx. Pour le reste, il y a certainement d’autres bibliothèques. Et puis, c’est une erreur de vouloir tout faire. Mais surtout, qt souffre du syndrôme mysql: une usine à gaz, certes open source, mais dont tous les droits pertinents sont détenues par une et une seule entreprise (et puis y a du nokia=crosoft derrière…) C’est du vendor-lock-in open source par la complexité. Donc, dans le choix d’un toolkit graphique, plutôt GTK+ ou les EFL (y en a d’autres plus spécialisés comme clutter avec un coût technique nettement plus faible), ensuite y a des finesses, mais je suis plus GNU GPL, donc j’aurais tendance à préférer le GTK+ (modulo les clutter and co),



Surtout le grand défaut de qt, c’est d’être écrit en c++, donc avec tous ses défauts et ses peu d’avantages. Pour ma part, cela l’élimine par défaut à cause de ça.



Un des défauts majeurs est l’intéropérabilité qui est un cauchemard à cause de l’ABI du c++… en gros il faut utiliser le même runtime c++ pour tout le monde. Car intéropérer avec d’autres framework/langages est déraisonnable, cf le JNI de java qui a le même pb…



Et quand Linus dit qu’il veut garder les codeurs c++ loin de linux, il a très peur des “délires objets” que se permettent pas mal de développeurs (j’ai le même avis). On me souffle à l’oreille qu’il suffit d’avoir une bonne hygiène de code, donc de ne surtout pas utiliser l’ensemble de l’orienté objet de la syntaxe, mais la réponse classique et que si on doit avoir une bonne hygiène de code autant l’avoir dans des langages comme le C, qui sont infiniment moins cher techniquement.



Bref,… je pourrais en écrire des tartines… " />

paradise a écrit :



Je me posais aussi la question de savoir ce que QT5 allait apporter à KDE, c’est le DE que j’utilise.







Ca fait longtemps que j’ai pas mis le nez dans leur roadmap, mais je pense pas (je peux me tromper) qu’ils passent à Qt5 avant une prochaine version majeure, qui ne sera utilisable qu’au bout de x versions mineures, donc rien, à mon avis, à court terme.

brazomyna a écrit :



Comme tout choix, ça a ses avantages et ses inconvénients. Tu as parlé des inconvénients, tu as oublié les avantages, dont celui fondamental: avoir un seul choix fait gagner du temps et la cohérence de l’ensemble est incomparable vis à vis de x librairies disparates, donc permet de gagner énormément en efficience ensuite.







Il me semble que tu n’as pas entendu parlé de la philosophie unix et son retour d’expérience sur près de 40 ans d’informatique: exactement le contraire de ce que tu avances… voir wikipedia.







brazomyna a écrit :



C’est TA vision du ‘bon’ ou ‘mauvais’ choix de licence, dont l’argumentation est d’autant moins vénérable qu’elle se sent obligée de donner dans le troll pour exister. D’autant que dans le monde réel, 90% des gens cherchent et/ou se satisfont de LGPL-like qui mèle accès aux sources pour comprendre le fonctionnement interne (et éventuellement le modifier à la marge), gratuité, et grande liberté de choix de licence pour leur code à eux qui vient par au-dessus.







Tu as raison, je suis connu pour ne pas être un GNU GPL fanboy… " />







brazomyna a écrit :



Idem qu’avant, tu fais tout pour parler des défauts sans mettre en balance les qualités indéniables d’une approche objet. Nul et non avenu, ou à défaut, tellement orienté que trop peu crédible.







ah? Je ne savais pas que l’approche objet était réservé à qt. Tu parlais peut-être de délirium objet pour qt? Car l’objet on en fait même en langage machine si on veut.







brazomyna a écrit :



L’argument autour de Linus étant ici le plus risible: en plus d’être un argument d’autorité (donc foireux par nature), il revient à dire que la solution technique n’est pas bonne parce que son utilisation par des gens qui ne savent pas s’en servir donne un résultat mauvais. Aussi pertinent que “un couteau est une mauvaise chose parce certains s’en servent pour tuer”. Voilà pour moi l’argument élu “argument de noël”.







aaaah! Enfin! Tous les troll ont une analogie FUDesque bien foireuse!







brazomyna a écrit :



Ca suffira, je pense, on a compris. Merci.







C’est triste mais je pense que tu n’as pas trop compris… désolé…



Et au delà d’une problèmatique de choix, il y a des absolus: un frontend de compilateur c++ avec son runtime et une ABI sont monstrueux en complexité par rapport à quasiment tous les autres langages (sauf java qui est sur la même échelle). C’est tellement déraisonnable qu’on pourrait relever de ses fonctions un codeur militaire pour folie furieuse! (moi aussi j’ai le droit aux analogies foireuses, y pas de raisons).



Perso, au lieux de faire du c++ avec une forte hygiène de code pour éviter de partir dans des délires d’usines à gaz objets, je préfère un peu de C, avec un peu d’orienté objet, juste ce qu’il faut, car c’est nettement moins coûteux techniquement pour les raisons précédentes. On perd indéniablement un peu en confort, car “l’orienté objet” n’est pas dans la syntaxe et gérée par un compilateur, mais c’est largement mieux que de s’enfermer dans l’horreur technique qu’est une implémentation c++… on a déjà linux, autant ne pas en rajouter capricieusement.



De plus, l’intéropérabilité objet du c++ n’existe qu’avec lui-même, voir de l’implémentation avec son l’ABI choisie (un vrai cauchemard!). Les trucs à la JNI, c’est juste pour se donner bonne conscience… d’ailleurs le standard c++ n’a même pas son “C++NI”… (d’ailleurs énormement de langages/framework ne sont intéropérables qu’avec eux même).



Ah et au fait, il y a un vrai problème sur le fait que qt/nokia/crosoft se mélangent joyeusement, comme il y a un vrai problème avec le fait que mysql soit tenu par oracle, comme le montre les migrations vers mariadb.



Joyeux Noyel!

divide a écrit :



…







Tu n’as pas saisi ce que je disais. Ce n’est pas une question de religion, c’est une histoire de compromis sur la complexité technique des composants logiciels vs la complexité de la syntaxe (orienté objet ou non)

Les ABIs des différents compilateurs c++ ne sont pas intéropérables aux dernières nouvelles, mais pour sûr sont toutes des délires en complexité technique. Pour sûr également, il n’y a pas d’équivalent dans le standard comme le JNI du java, donc le c++ ne travaille qu’avec du c++, sauf si il y a un effort conséquent pour le rendre intéropérable avec les autres langages (en général, une API en C/un protocole réseau…). Attention, je n’encourage pas le JNI, car c’est juste du masochisme que de coder dans ce truc. Pour sûr également, la complexité du langage c++, de son runtime avec son ABI, fait que c’est un kludge délirant.

À la lumière de ce que je viens de dire, oui je préfère m’embêter un peu plus à coder un peu de plomberie objet en C, que de dépendre d’un super-ultra-giga-kludge. Cela dans un soucis d’abaisser le coût technique des composants nécessaires pour faire tourner mon code (linux est déjà horriblement complexe, pas la peine d’en rajouter). Tu as le droit de choisir de “payer” le prix de la dépendance sur le kludge au c++, mais ne l’impose pas à ceux qui ont choisit des langages/frameworks plus simples, et pour pouvoir travailler avec eux, soit intéropérable, ce qui signifie dans le monde d’aujourd’hui que tu as un protocole réseau et/ou une API en C (l’alpha/l’omega d’un système informatique).

Si tu as suivi l’actualité de qt/nokia/crosoft… c’est dans le même plan de manipulation que novell/crosoft. Ils sont “grillés”. Dans le milieu linuxien, il n’est pas rare de considérer la distribution gnu/linux suse comme la distribution crosoft… Simplement, la méthode du “proxy” est moins voyante que la méthode employée par oracle… d’ailleurs il y a une telle confiance et une telle entente qu’ openoffice a été forké en libreoffice qui est maintenant le kludge “office” officiel, et je vois un peu partout des remplacement de mysql par du mariadb.



" />