• # A mon avis rien n'est fait

    Posté par  . Évalué à 8. Dernière modification le 20 mai 2015 à 17:49.

    Qt est vraiment super mais, et c'est un enorme mais, le nouveau model de Qt fait que cela va devenir de plus en plus complique de developper (en dehors de truc plus ou moins basique ou utilisant autre chose comme KDE) avec:

    http://www.qt.io/download/

    Quand on voit ce qui n'est pas dans la partie community ca commence a faire beaucoup: QtChart, Qt Data Visualisation, Qt Virtual Keyboard (pas pratique pour pas mal d'applis sur mobile).

    Et surtout l'enorme probleme de ce toolkit (pour linux) c'est l'archi dominance des bureaux a base de Gtk. Je sens pas trop le passage a KDE5. Enfin bon qui vivra verra.

    • [^] # Re: A mon avis rien n'est fait

      Posté par  (site web personnel) . Évalué à -5. Dernière modification le 20 mai 2015 à 19:49.

      En fait, Qt, malgré ses 36 changements de propriétaire, n'a pas foncièrement changé dans l'esprit : utiliser le libre comme produit d'appel pour vendre du non libre; ça avait commencé avec la GPL pour Linux mais pas libre pour Windows, et maintenant c'est une version "communautaire" de plus en plus légère (e comparaison) et tous les modules "modernes" non libres.

      Dommage, c'était un bon toolkit libre, maintenant il se transforme en bon outil non libre avec une part (celle non vendable facilement) libre de plus en plus petite en pourcentage (le libre ne s'est pas transformé en non libre, c'est seulement les ajouts qui sont non libres). Et surtout, maintenant il ne suffit pas de faire du libre pour avoir le droit d'utiliser tout, les libristes non plus de bonus, traité au même niveau que du non libre (on ne peut donc même pas faire du libre GPL avec les nouveaux modules)

      Y a-t-il un business model viable pour un toolkit 100% libre qui n'aurait pas de business model non libre? Telle est la question…

    • [^] # Re: A mon avis rien n'est fait

      Posté par  . Évalué à 10. Dernière modification le 20 mai 2015 à 20:32.

      Au contraire Qt propose de plus en plus de modules libres. Rien que dans la version 5.5 on trouve deux nouveaux modules Qt3D et Canvas3D sous licence libre. De plus une partie importante qui était sous licence propriétaire, les Qt Quick Enterprise Controls de ton lien, devient accessible dans la Community Edition.

      Suggérer qu’il devient difficile d’utiliser la bibliothèque parce qu’elle ne possède pas, dans son installation standard, de fonctions de plotting et d’un clavier virtuel c’est un peu gros. De mémoire libgtk-3.so ne fourni pas non plus de plotting. De plus rien n’empêche de lier un programme à d’autres bibliothèques, à moins d’être vraiment un branquignole du terminal. Rien que pour le plotting il existe pas mal de possibilités libre (au hasard, le premier lien du moteur de recherche est sous GPL).

      • [^] # Re: A mon avis rien n'est fait

        Posté par  . Évalué à -1.

        devoir utiliser une bibliothèque tierce qui va forcément s'intégrer mal avec le reste de Qt, tant un niveau du code et des habitudes (il va falloir s'habituer à une autre API pour ceci ou cela), c'est un peu chiant quand même…

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: A mon avis rien n'est fait

      Posté par  . Évalué à 10.

      Et surtout l'enorme probleme de ce toolkit (pour linux) c'est l'archi dominance des bureaux a base de Gtk

      En quoi est-ce un problème ? Ton gnome ou xfce n'autorise pas le lancement d'applications Qt ??

      Perso j'utilise KDE avec des logiciels Qt ou Gtk, ça marche très bien.

  • # Réponse ?

    Posté par  (site web personnel) . Évalué à 10.

    d'après vous quel sera le prochain gros logiciel à dire adieu à GTK ?

    Gnome ?

    kentoc'h mervel eget bezan saotred

  • # C++ / Modèle Objet

    Posté par  . Évalué à 0.

    Le truc qui me peine vraiment avec Qt est que son modèle objet est fortement lié à celui du C++ .

    Ca rend le binding difficile pour certains langages et en plus ca le prive de technos innovantes comme Core Data ou son équivalent libre Core Object.

    Mon idéal serait donc un Qt reposant sur un modèle objet indépendant du langage. Et oui: gobject + Qt !

    • [^] # Re: C++ / Modèle Objet

      Posté par  (site web personnel) . Évalué à 7.

      Heu, ils ont quand même choisi C++… à cause du support de la POO dans le langage, ça aurait été c** de ne pas l'utiliser. Si tu veux un modèle objet en C avec les contraintes qui vont avec… y'a GTK.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: C++ / Modèle Objet

        Posté par  . Évalué à 8.

        Premièrement attention gtk ≠ gtkmm ≠ gobject ≠ glib .

        Le problème de Qt c'est qu'ils se veulent multi plates-formes et multi langages…

        Le modèle QObject est une surcouche du modèle de C++ et donc cela impose que les autres langages puissent se contorsionner pour rentrer dans ce modèle.

        En revanche, les modèles d'objets de GTK et de Cocoa (OpenStep),respectivement GObject et libobjc, sont écrits indépendamment d'un langage. Dans les deux cas tu peux écrire un programme en C pure si tu as envie (avec tout le glue code que cela implique) mais aussi contrairement à ce que tu indiques en langage de haut niveau type C++ ou objective-C ou SWIFT ou vala ou c# …
        A ce moment là, la classe objet de base court-circuite le modèle objet propre au langage pour utiliser celui externe (ce qui relativement facile à faire). Ainsi tu codes en gtkmm (le binding c++ de gtk) comme si tu codais en c++ sans le glue code. Idem pour Cocoa en c++.

        Comme effet de bord, ça permet de s'échanger des classes entre langages différents ce qui pour rappel n'est pas standard même entre deux compilos de c++.

        Essayes d'utiliser une classe héritant de QObject écrite en Java dans un programme en python…tu vas pleurer.

        • [^] # Re: C++ / Modèle Objet

          Posté par  (site web personnel) . Évalué à 4.

          contrairement à ce que tu indiques

          Je n'indiques rien de tel.

          Finalement, je ne vois pas trop l'intérêt de chercher à mixer trop de choses différentes en essayant que ça soit tout intégré dans tous les sens.

          À part si tu arrives à avoir une techno avec une couche qui établis un élément commun entre tes différents langages (sauf erreur Microsoft le fait avec le CLR, ce qui permet de mixer les C# F# IronPython etc) et alors tu peux vraiment mixer de façon transparente.

          Si tu utilises des choses comme swig pour wrapper ta librairie langage compilé (objet éventuellement) vers des langages autres, ça te permettra de l'utiliser facilement dans ces langages… mais autant éviter les emmerdes en ne cherchant pas à faire tout dans tous les sens. Au pire, un spawn() qui va bien et de la communication inter-process… si on a vraiment besoin que les différents langages communiquent - chacun garde son mode de fonctionnement, son modèle objet, son modèle de traitement des errerus… chez lui.

          Essayes d'utiliser une classe héritant de QObject écrite en Java dans un programme en python…tu vas pleurer.

          Je n'ai même pas envie d'essayer—surtout pour me taper du Java.

          Ceci dit, j'ai déjà mixé du Python + C++ dans le même process via CORBA (FNORB à l'époque, je suis passé à omniORB ensuite) - ça marchait, et pour peu que le runtime d'un langage soit "embarquable", ça doit encore marcher (bon, l'idée avec CORBA c'est que ça pourrait très bien être dans un autre process, ça marcherais pareil).

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 2.

            C++ et langage X avec Qt çà va encore mais c'est quand il y a ménage à trois que le statut change pour "C'est compliqué"…

            Et avec la volonté de Qt de pousser à ce que la vue soit codé en JS çà va arriver vite.

        • [^] # Re: C++ / Modèle Objet

          Posté par  . Évalué à 3.

          En revanche, les modèles d'objets de GTK et de Cocoa (OpenStep),respectivement GObject et libobjc, sont écrits indépendamment d'un langage.

          Je ne vois pas ce qui, conceptuellement, empêcherait le modèle objet C++ d'être manipulable depuis du code C (d'ailleurs, les premiers compilateurs C++ étaient de simples traducteurs C++ vers C). Il faut juste écrire le code pour ça.

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 4.

            Tu n’as pas d’API C standardisée pour appeler du code C++ depuis d’autres langages avec les conventions d’appel C. L’équivalent de JNI de Java, ou de libobjc d’Objective-C quoi.

            Et une telle lib serait spécifique à l’architecture et au compilateur C++ lui-même (name mangling et autres joyeusetés)

    • [^] # Re: C++ / Modèle Objet

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 21 mai 2015 à 09:33.

      C'est vrai que c'est tellement bien un toolkit en C :

      gtk_window_create_with_my_very_large_number_of_parameters(GTK_WINDOW(myobject), g_utf_text_from_char("je dis oui"));
      Sans compter les macros de merde pour déclarer un objet en glib. C'est vrai, c'est tellement mieux de réinventer la roue pour faire de l'OO avec un langage qui ne le permet pas nativement au lieu d'utiliser un qui le permet. Avec C++, on a RAII, les exceptions, l'orienté object (prérequis pour un toolkit), l'overload, les namespaces, … Mais bon, certains dinosaures préfèrent écrire du code en 30 lignes et à s'amuser à chercher où il manque des free plutôt que d'utiliser un langage moderne.

      Un code Qt est beau, propre et facile. Avec C++14 ça l'est encore plus.

      J'ajoute aussi que Gtk sur les plateformes non Linux c'est une grosse blague. Testez geany, gimp sur Windows, vous allez pleurer. À l'inverse une application Qt est presque native visuellement, je regarde TortoiseHg, VirtualBox, on pourrait croire qu'ils sont développés directement avec le toolkit du système.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: C++ / Modèle Objet

        Posté par  . Évalué à 3.

        Merci de passer sous silence l’existence de gtkmm pour gobject ou de swift pour libobjc…

        Clairement Qt est mieux foutu (aussi bien pour l'utilisateur que pour le dev) que GTK. Par contre, c'est vraiment la misère pour s'interfacer avec un autre modèle objet.

        • [^] # Re: C++ / Modèle Objet

          Posté par  (site web personnel) . Évalué à 3.

          D'un point de vu utilisateur, je ne suis pas sur de voir les avantages de Qt sur GTK+ :)

          D'un point de vu dev, Qt est un framework et GTK+ ne l'est pas, donc pas vraiment comparables :)

          Par contre, je trouve que GTK+ fait de gros progrès depuis un an, après avoir été lâchement mis de coté à la sortie de GNOME3.

          Pour Qt, j'espère que depuis le passage en gouvernance ouverte et l'implication des devs KDE, j'espère que les choses vont mieux niveau résolution des rapports de bugs, parce que du temps de Nokia, les bugs Qt trouvés dans des softs libres, c'était un peu: "Rien à branler"

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 0.

            Mouhais j'espere que tu as raisons le probleme c'est que j'ai l'impression que le navire KDE est en train d'avoir des fuites de partout et de moins en moins de devs. Ce qui est comprehensible car aucune distribution majeur ne le propose plus par defaut et celle qui le propose s'est souvent moyen l'integration. J'ai plusieurs bugs ouvert sur KDE5 depuis plusieurs mois et contrairement a il y a quelques annees. Il n'y a … rien qui se passe dessus. Donc l'implication des devs KDE dans Qt c'est peut etre une bonne idee mais j'ai peur que cela ne soit pas trop faisable. Je suis tres inquiet sur l'avenir de ce bureau. Qt cela devrait aller pendant encore quelque temps mais bon ils vont bientot rentrer en conflit avec .Net…

            • [^] # Re: C++ / Modèle Objet

              Posté par  . Évalué à 5. Dernière modification le 21 mai 2015 à 13:23.

              Ce qui est comprehensible car aucune distribution majeur ne le propose plus par defaut

              définis distribution majeur ?

              Et si il y a quand même :

              • Kubuntu (financé par Blue Systems, qui finance aussi en partie la fondation KDE et emploie certains dévs KDE), une distribution majeure (de part sa popularité, longévité, et son support des versions LTS sur 5 ans) s'il en est.

              • PC-BSD (ben oui t'as pas dis "distribution Linux" ;-) )

              • OpenSUSE

              • PCLinuxOS

              • KaOS

              • Pardus

              • Chakra Linux

              • Linux Mint (variante KDE. C'est comme Mageia, y'a pas vraiment de variante plus officielle qu'une autre)

              • Mageia (qui est historiquement plutôt centrée sur KDE, et qui propose plusieurs environnements de bureaux sur ses LiveCD et ses DVD d'installation, et non pas un bureau en particulier)

              • Slackware (source 2)

              • sûrement d'autres parmi cette longue liste !

              AUCUNE, vraiment ?!

              Qt cela devrait aller pendant encore quelque temps mais bon ils vont bientot rentrer en conflit avec .Net…

              A la limite avec WPF, mais comme ce dernier n'est pas multi-plateformes on s'en fiche.

              Non, vraiment, je vois pas le rapport avec .NET…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: C++ / Modèle Objet

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 21 mai 2015 à 10:07.

        Personne ne t'oblige à utiliser le language C pour faire un programme GTK+. C'est son gros avantage, la fonction_avec_un_nom_super_long existe en version courte dans tous les langages objets supportés par gobject introspection…

        Sous Qt, c'est plus: "Elle est trop cool cette fonction mais merde mon binding peu maintenu ne la supporte pas"…

        Par contre, en pur C++, c'est sur que Qt est vraiment bien mais par contre, il semble que l'utilisation d'exceptions ne fasse par partie de la philosophie des développeurs Qt ;)

        • [^] # Re: C++ / Modèle Objet

          Posté par  . Évalué à 3.

          par contre, il semble que l'utilisation d'exceptions ne fasse par partie de la philosophie des développeurs Qt

          Comme pas mal de gens, à commencer par Google, vu que c’est assez chiant de faire des garanties sur du code qui va lancer des exceptions.

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 3.

            Chez Google ils ne sont pas très catégoriques sur ce choix. D'après le lien que tu cites ils évitent les exceptions pour des raisons d'intégration avec la base de code existante.

            On their face, the benefits of using exceptions outweigh the costs, especially in new projects.

            Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

      • [^] # Re: C++ / Modèle Objet

        Posté par  . Évalué à 1.

        Sans compter les macros de merde pour déclarer un objet en glib. C'est vrai, c'est tellement mieux de réinventer la roue pour faire de l'OO avec un langage qui ne le permet pas nativement au lieu d'utiliser un qui le permet.

        Alors que les macro qobject avec un outil pour venir manipuler tout ça avant la phase de compilation c'est d'une propreté incroyable et ça ne réinvente pas du tout la roue (mais vraiment pas).

        Un code Qt est beau, propre et facile. Avec C++14 ça l'est encore plus.

        Un code Qt n'est pas du C++, c'est proche, mais ça n'en est pas. Tu donne ton code Qt à ton compilateur C++ qui respecte le standard C++, ça ne fonctionne pas.

        Donc non faut arrêter de dire que :

        1. c'est propre
        2. c'est du C++

        Sinon il faut dire qu'ObjectiveC est du C beau propre et facile.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 7.

            Pour fonctionner, Qt utilise un préprocesseur (moc), qui va générer du code. Si on compile directement le fichier cpp, ça ne marchera pas.

            Il n'existe actuellement pas d'alternative en C++ standard, par exemple pour appeler une fonction par son nom.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 4.

              Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: C++ / Modèle Objet

              Posté par  . Évalué à 3. Dernière modification le 21 mai 2015 à 19:22.

              Il n'existe actuellement pas d'alternative en C++ standard, par exemple pour appeler une fonction par son nom.

              Tu peux y aller à coup d’appels invokeMethod, avec une compilation sans faire appel à moc. Tu as besoin de moc uniquement pour aider à définir le modèle QObject d’une nouvelle classe. Mais évidemment ce n’est pas obligatoire, c’est juste chiant de définir à la main les meta-données d’une classe.

              Pour des méthodes C++, pas besoin d’utiliser les fonctions de invokeMethod, elles restent des fonctions C++ standards appelables directement. C’est par contre nécessaire pour des QObjects écrits dans d’autres langages comme QML.

          • [^] # Re: C++ / Modèle Objet

            Posté par  . Évalué à 4.

            Eventuellement l'éditeur de lien non (s'il manque les morceaux générés). Mais la compilation elle se fera sans soucis.

            Bon si tu veux qu'on s'attaque aux mouches…

            Par compilateur j'entends l'ensemble des outils qui servent à passer d'un code source d'un langage A vers un langage B dans le cas présent A=C++ et B le binaire de l'architecture qui te convient et par "fonctionner" j'entends qui puisse s'exécuter en ayant le comportement attendu à la lecture du code source.

            Donc j'affirme si Qt c'est du C++, le dialect pythran c'est aussi du C++.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 7.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: C++ / Modèle Objet

                Posté par  . Évalué à 1.

                Donc Qt intervient dans la chaîne de compilation, pas la compilation elle-même.

                Il fait partie de la norme C++ ? (c'est ce que je dis dans mon premier message)

                Sinon je peux dire qu'avec mon super framwork on peut remplacer tous les ; par des × et mon framwork c'est sed 's/×/;' et continuer à dire que je code en C++.

                Que fait Qt ?

                Parlons plus sérieusement. Qt modifie la manière dont un code C++ s'execute, il ajoute un tas de choses qui sont impossibles dans le langage standard et il le fait en étendant le langage plutôt que par des bibliothèques ou framework. Compare la manière dont boost et Qt permettent de gérer des signaux/slot l'un est une bibliothèque et l'autre le fait de manière bien plus intrusive.

                Je ne dis pas que c'est mal ou qu'ils ont tord de le faire. Je dis qu'ils ont suffisamment tordu le langage pour qu'on arrête de dire que c'est du C++. Inutile de le prendre comme une insulte, ils ont commencé à utiliser C++ à une époque où ils étaient obligés de faire ce genre de manipulation pour arriver à leurs fins.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 7.

                  Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: C++ / Modèle Objet

                  Posté par  (site web personnel) . Évalué à 7.

                  Je crois que tu ne comprends pas ce que moc fait. moc ne modifie pas tes fichier C++. moc génére juste un fichier C++ additionel contenant l'implémentation des signal et de quelques functions déclarées par la macro Q_OBJECT .
                  Le code que tu écris est du C++ pur 100% conforme.

                  Pour plus d'information je t'invite à lire mon article: http://woboq.com/blog/how-qt-signals-slots-work.html

                  moc est juste un générateur de code, et les générateurs de code ne sont pas mauvais. Est-ce que LLVM/clang est écrit en C++ ? pourtant, certains fichier en-têtes sont automatiquement générer avec TableGen . Peut on encore dire que le noyau Linux soit écrit en C alors que les headers dans include/generated néssécite d'être générer par le système de build ?

              • [^] # Re: C++ / Modèle Objet

                Posté par  . Évalué à 2.

                Tu sais quoi ? Il y a beaucoup d'outils qui peuvent intervenir dans la chaîne de compilation. Les plus connus et utilisés sont les autoconf et consort. Est-ce que ça veut dire que si je les utilise, je ne fais pas du C ou du C++ ? Car après tout, je prend n'importe quel projet qui dépend de ces outils et je serais bien malin avec juste mon compilateur et les sources…

                Je crois que le malaise vient de là.
                En théorie on devrait avoir besoin des fichiers sources (.c, .ccp, autres ressources + fichier config) et on aurait juste à lancer la moulinette avec un compilateur "standard", comme :

                mon-compilateur-qui-respecte-la-norme mon-fichier-config

                Sauf que le fichier de configuration (makefile, …) ne fait pas parti du standard, du coup on se tape des dizaines d'alternatives à ce qui aurait du être intégré d'office dans l'écosystème du langage. Et bien évidemment cela mène au bordel monstre qu'on connaît, Qt est juste un acteur de plus, et à mon avis ce n'est pas le pire.

                D'ailleurs j'adore leur Qt Build Suite, un genre de CMake, indépendant de Qt, évidemment cross-platform , extensible, avec un langage déclaratif (du Qml, qui ressemble à du Javascript), qui peut prendre en compte tout plein de langages.

                • [^] # Re: C++ / Modèle Objet

                  Posté par  . Évalué à 3.

                  Tout à fait le problème que les p'tits gars de Mozilla ont cherché à résoudre avec Cargo (pour Rust).

                  Côté Java, la norme ne prévoit rien, mais le standard de fait c'est Maven.

                  Et c'est vrai qu'on y gagne à avoir des outils normalisés.

        • [^] # Re: C++ / Modèle Objet

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 21 mai 2015 à 15:18.

          Moc est là pour rajouter une couche d'introspection qui n'existe pas dans C++ malheureusement. On peut pas faire autrement avec un langage aussi statique et typé. Cette fonctionnalité permet de pouvoir appeler une fonction par son nom ce qui est assez pratique avec le système signaux/slot qui supportent les overloads.

          On pourrait très bien faire sans, en utiliser juste une liste de std::function sauf que Qt, ça a un passé et ça évolue petit à petit.

          Je précise que sans ça, ça serait difficile d'implémenter des interface depuis les .ui. En effet, ces fichiers XML peuvent déjà aider à mettre des signaux/slots au moment du chargement de l'UI et tout ça de manière sécurisé puisque moc va créer des vrais fonctions typés. Alors qu'une alternative utilisant dlopen serait totalement non-typé.

          git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: C++ / Modèle Objet

        Posté par  (site web personnel) . Évalué à 5.

        C'est vrai que c'est tellement bien un toolkit en C :

        Quand on programme en C, c'est plutôt utile non?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.