Journal LXDE, Razor-qt et Qt (et GTK+)

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
45
6
juil.
2013

Les choses bougent depuis quelques mois du côté de LXDE, le bureau X léger basé sur GTK+ 2.

Enfin basé sur GTK+ 2, plus pour longtemps. Leur toolkit de prédilection n'est plus maintenu et porter à moyen terme le bureau vers un toolkit plus moderne et surtout toujours maintenu semble une chose judicieuse. Seulement contre toute attente, ce n'est pas GTK+ 3 qui a été retenu mais Qt (Qt 4 dans un premier temps puis Qt 5.1 ensuite). Ce choix semble être dicté partiellement par pragmatisme et partiellement par une préférence des développeurs de LXDE (y compris son fondateur PCMan) pour Qt et le C++.

La version Qt du bureau a dépassé l'état de concept et bien que manquant de finition elles est maintenant utilisable ; l'application phare du bureau, PCManFM, a été portée sur Qt avec succès et peut dessiner le bureau ; enfin un nouveau visionneur d'image nommé LxImage-Qt remplacera GPicView.

Et Razor-qt dans tout ça ? Le bureau au rouleau à pizza encore jeune est moins mature que LXDE, en a sensiblement les même buts mais se base quant à lui sur Qt.

Les deux bureaux ayant désormais des buts identiques, un look identique et se basant sur les mêmes technologies, la communication est née et des collaboration sont à prévoir, comme la bonne intégration des application d'un bureau dans l'autre.

Bien qu'étant un choix purement technique et sans énorme incidence sur l'utilisateur final, le choix du toolkit graphique est sujet à débattroll dans le milieu des geeks libristes.

Qu'est-ce que Qt a de si merveilleux ? GTK+ 3 est-il si pourri que ça ? N'ayant jamais touché qu'au second et jusque là avec plaisir, j'espère que vous pourrez éclairer ma lanterne avec toute l'objectivité possible (ce journal arrive malheureusement un jour trop tard pour troller ouvertement).

  • # bof

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

    Le troll a déjà eu lieu de nombreuses fois.
    Comparer Qt à GTK, c'est comme comparer un atelier complet à un marteau, ça n'a pas de sens.

    • [^] # Re: bof

      Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 06 juillet 2013 à 19:47.

      De ce que je crois comprendre (après recherche suite à ta réponse) GTK+ serait plus comparable au module QtGui tandis que Qt dans son ensemble serait plus comparable à la plateforme GNOME (GLib, GObject, GTK+, WebkitGTK+, GStreamer, Anjuta, Glade…) ?

      • [^] # Re: bof

        Posté par  . Évalué à -2.

        Qt dans son ensemble serait plus comparable à la plateforme GNOME (GLib, GObject, GTK+, WebkitGTK+, GStreamer, Anjuta, Glade…)

        Il ne serait pas si complet que ça, puisque KDE a eu besoin d'en rajouter une couche en développer ses kdelibs.

        D'ailleurs, qu'en est-il de l'intégration de Phonon dans Qt ? J'avais cru comprendre que c'était prévu mais que ça ne sera finalement pas maintenu ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: bof

          Posté par  . Évalué à 4.

          D'ailleurs, qu'en est-il de l'intégration de Phonon dans Qt ?

          Ça a été fait mais ça a été retiré au profit de Qt Multimedia.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: bof

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

          les libs kde sont principalement destinée à implémenter des fonctionnalités "métier" liées au bureau KDE lui-même, pas forcément à étendre les fonctionnalités purement "IHM" (au sens large) (y'en a quand même hein, mais c'est essentiellement des composants spécifiques qui sortent un peu du champ d'un framework "généraliste" tel que Qt)
          Bon après, pour vraiment comparer, il faut avoir une connaissance bien complète des deux côtés, je ne sais pas si on peut trouver beaucoup de gens capables d'avoir ces deux casquettes. Surtout vu l'étendue fonctionnelle de ce genre libs en 2013… personnellement je n'essaye même plus de regarder l'arbre des classes de Qt pour ne pas avoir peur :)

      • [^] # Re: bof

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

        C'est plus juste en effet, en ajoutant que c'est un bureau Gnome portable sous Windows, MacOs, tous les unix et Android, avec un look natif sur toutes les plate-formes citées.

  • # Temps

    Posté par  . Évalué à 10. Dernière modification le 06 juillet 2013 à 21:02.

    Qu'est-ce que Qt a de si merveilleux ? GTK+ 3 est-il si pourri que ça ?

    (vu sur la ML) PCMan et les autres dév. de LXDE se plaignent de la lourdeur et des bugs de GTK3. PCMan a aussi annoncé qu'il a mis moins de temps à réécrire certaines applications en C++/Qt qu'à les migrer de GTK+ 2 à GTK+ 3.

    Le vent semble avoir tourné pour LXDE vu qu'il existe LXpanel-Qt et PCManFM-Qt, peut-être d'autres applications dont je n'ai pas vu passer l'annonce, cela même si ils écrivent qu'ils restent sur GTK+ 2.

    The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

    • [^] # Re: Temps

      Posté par  . Évalué à 10. Dernière modification le 06 juillet 2013 à 23:57.

      PCMan et les autres dév. de LXDE se plaignent de la lourdeur et des bugs de GTK3.

      Cela me fait penser que, l'usage mémoire inquiétant (au début) de GTK3 et le manque de force de travail a fait que le projet Xfce a retardé le passage à GTK3 à après la version 4.12 (qui préparera le terrain, en plus d'apporter des améliorations).

      Sur la ML, le passage aux bibliothèques EFL a été envisagé, mais comme GTK3 a fini par s'améliorer du point de vue de l'usage mémoire, et comme passer à ELF (ou Qt) impliquerait une ré-écriture de tout le code de Xfce, il a été décidé de rester sur GTK et les technologies "associées" (Gvfs, …).

      Pour ma part j'espère qu'on va arrêter d'avoir des thèmes GTK3 pour chaque version de GTK3 (GTK 3.2, GTK 3.4, GTK 3.6, …), c'est d'un ridicule…

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

      • [^] # Re: Temps

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

        Pour ma part j'espère qu'on va arrêter d'avoir des thèmes GTK3 pour chaque version de GTK3 (GTK 3.2, GTK 3.4, GTK 3.6, …), c'est d'un ridicule…

        C'est aussi le cas pour les extensions de Gnome 3. On dirait Firefox et ses incompatibilités entre les versions…

  • # subsurface

    Posté par  . Évalué à 6.

    On peut noter que subsurface, un projet créé par Linux qui en connu pour ne pas être fan de c++ (c'est un euphémisme) migre lui aussi vers Qt

    http://subsurface.hohndel.org/

    • [^] # Re: subsurface

      Posté par  . Évalué à 10.

      s/Linux/Linus/

      De rien.

      • [^] # Re: subsurface

        Posté par  . Évalué à 2.

        Et en plus j'y ai pensé en rédigeant

    • [^] # Re: subsurface

      Posté par  . Évalué à 1.

      Tu peux donner une référence qui parle de ça? j'ai rien vu sur le lien.

      • [^] # Re: subsurface

        Posté par  . Évalué à 10.

        https://github.com/torvalds/subsurface

        After the release of Subsurface 3.1 we merged the Qt branch into master and are now developing the Qt port of Subsurface in the master branch.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: subsurface

          Posté par  . Évalué à 4.

          Il y a aussi des posts G+ de Linus demandant de l'aide sur la partie Qt, les développeurs principaux n'ayant pas d'expertise sur ce domaine.

        • [^] # Re: subsurface

          Posté par  . Évalué à 0.

          euh wait j'ai peur de ne pas très bien comprendre là…on part sur Qt parce que c'est mieux ou plus facile mais il faut de l'aide externe…pour le coup je suis pas sûr de très bien comprendre l'interêt de cette "migration".

          Peut être qu'en lisant des trucs de Linus sur ça je comprendrai.

  • # TortoiseHG aussi

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

    Un des clients mercurial les mieux foutus que j'ai rencontré a aussi migré de Gtk a Qt. On vous l'avait dit il y a 10 ans, vous ne vouliez pas nous croire !

    Pour moi, l'argument no 1 de Qt reste la portabilité. Il y a beaucoup d'autres atouts mais pour une application moyenne développée en Gtk, la partie graphique de Qt même si elle est plus simple ne fera pas un tel différentiel. La différence se voit surtout :
    - pour des applis complexes
    - dès que tu veux porter sous Windows

    Là, c'est assez violent. Le portage de Gtk sous Windows reste une grosse grosse difficulté.

    • [^] # Re: TortoiseHG aussi

      Posté par  . Évalué à 2.

      Le plus drole ce fut l' utilisation de wxwin rebaptise wxwidget un truc base sur Gtk2 et qui casse la compatibilite source (et binaire) a chaque increment meme mineur. Tout ca pour faire un concurrent a Qt…

  • # Qt vs Gtk

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

    Qu'est-ce que Qt a de si merveilleux ? GTK+ 3 est-il si pourri que ça ?
    

    Oui, QT est propre, plus rapide et plus performant. Gtk c'est une horreur en C voulant simuler de l'orienté objet avec un langage qui ne le prévoit pas. Du coup ça donne du code dégueu et incompréhensible.

    Il n'y a qu'à regarder comment faire un GObject, ça fait vomir.

    Et puis, gtk_widget_create_full_parameter_c_est_vraiment_relou_a_ecrire_cette_function();

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

    • [^] # Re: Qt vs Gtk

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

      Moaurf, le super argument pas has been du tout: « GTK c'est pourri parce que c'est en C »… Les bindings C++, python, etc. c'est fait pour les chiens ? Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout. Au moins je me pose pas la question de savoir OuJeDoisMettreDesMajusculesQuandIlYAUnSigleCommeGTK. Bref, quel que soit le langage, suffit d'apprendre à coder. Mettre des underscore utilise autant d'appuis de touches que d'appuyer sur shift. Mais c'est sûr, c'est plus long si tu es un dinosaure qui imprime son code sur papier.

      • [^] # Re: Qt vs Gtk

        Posté par  . Évalué à 7.

        Les bindings C++, python, etc. c'est fait pour les chiens ?

        Enfin les bindings sont encore plus dégueux (comme la plupart des bindings tu me diras), mélangeant les structurations objets.

        • [^] # Re: Qt vs Gtk

          Posté par  . Évalué à 8.

          ce qui est surtout degue dans les bindings c'est la doc! Enfin si on peut appeler degueu un truc inexistant!

          • [^] # Re: Qt vs Gtk

            Posté par  . Évalué à 2.

            Je pense que la plupart des auteurs de binding pensent que la doc des fonctions C dessous suffit.
            N'ayant pas utilisé un des ces bindings, j'ignore s'ils ont raison où pas.

            Non le plus gros problème de ces bindings, c'est qu'ils sont souvent incomplet et peu mis à jour..

          • [^] # Re: Qt vs Gtk

            Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 09 juillet 2013 à 18:03.

            La doc Vala est pas mauvaise, je trouve. Mais ça reste l'exception qui confirme la règle.

      • [^] # Re: Qt vs Gtk

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

        Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout. Au moins je me pose pas la question de savoir OuJeDoisMettreDesMajusculesQuandIlYAUnSigleCommeGTK. Bref, quel que soit le langage, suffit d'apprendre à coder.

        Le commentaire auquel tu réponds y va un peu fort, mais je suis allé voir comment on hérite d'un objet en GTK (ou bien d'un QObject), et j'ai fui immédiatement. 3 km de boilerplate code, non merci. /o\
        Je comprends l'intérêt de projets comme Vala, par exemple…

        • [^] # Re: Qt vs Gtk

          Posté par  (site web personnel) . Évalué à -1. Dernière modification le 10 juillet 2013 à 00:06.

          Donc tu as comparé comment faire de l'héritage en C++, et comment faire de l'héritage en C avec GObject. C'est sûr que c'est moins simple en C on est d'accord, mais là c'est plus de la comparaison GTK vs Qt, c'est de la comparaison C vs C++. Autant comparer GTKmm à Qt (et là il y aura plein de critiques justifiées), sinon ce n'est pas vraiment équitable…

          • [^] # Re: Qt vs Gtk

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

            En même temps, c'est toi qui écris que "Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout." et que "Bref, quel que soit le langage, suffit d'apprendre à coder.".

          • [^] # Re: Qt vs Gtk

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

            c'est plus de la comparaison GTK vs Qt, c'est de la comparaison C vs C++.

            Je vais faire mon Zenitram : c'est vraiment de le pure mauvaise foi pour ne pas reconnaître une très grosse faiblesse de Gtk: c'est fait en C et ça pue pour l'héritage et plus généralement les fonctionnalités Objet.

            On parle bien de comparer Gtk avec son implémentation de référence et Qt avec son implémentation de référence. Et pas d'un binding Gtk quelconque avec Qt, ou d'un binding Qt quelconque avec Gtk.

            Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.

            Pour faire un reproche équivalent à Qt (et me dédouaner de toute accusation de partialité), on peut reprocher à Qt le fait de n'être pas du C++ mais du C++ avec une surcouche gérée par l'outil Moc.

            Je ne te répondrai pas que le reproche est débile, et qu'il faudrait comparer boost.signal avec Qt pour être honnête (comme tu viens de le faire). Ou bien que tu n'as qu'à faire du PyQt où le moc n'est pas utilisé.

            C'est vrai que Moc est indispensable pour faire du Qt, mais ça permet de pallier avec élégance (et une petite complexité à la compilation) à un manque de fond du C++.

            • [^] # Re: Qt vs Gtk

              Posté par  . Évalué à 0. Dernière modification le 20 août 2013 à 23:33.

              Et bien malgré ces arguments (que je ne contredit pas) je trouve que GNOME (2 et 3) m'a toujours semblé bien plus stable et mature que KDE à l'utilisation (ce n'est peut-être qu'une impression), ce dernier me parait visuellement dégueulasse si l'intégration n'est pas poussée. Donc si je devais me baser sur ces 2 DE pour faire un choix, je choisirais Gtk.
              N'oublions pas que Gtk a jusque ici toujours était largement en supériorité en ce qui concerne les DE/WM (en fait je ne connais aucun autre WM utilisant Qt).

            • [^] # Re: Qt vs Gtk

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

              Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.

              C'est vrai que GTK est insupportablement bavard… ceci dit, bien que ne connaissant pas Qt, je connais assez C++ pour suspecter QT d'être lui aussi très bavard — de façon peut-être supportable.

              En ce qui concerne l'écriture d'applications évoluées, l'extension du toolkit n'est pas du tout la bonne méthode. Ce qu'il-faut-faire™, c'est écrire un nouveau toolkit décrivant l'interface de l'application avec des éléments de très haut niveau et puis implémenter le toolkit de haut niveau avec un toolkit de bas niveau comme Gtk. La raison de faire ainsi est qu'on s'assure de l'homogénéité de l'interface de l'application et qu'on maîtrise complètement la surface d'utilisation du «tiers code» ce qui est un atout pour la maintenance (mise à jour ou changement du toolkit de bas niveau). Donc du coup on se contrefiche complètement que Gtk soit écrit en C et pas en C++.

  • # Qt 4 dans un premier temps puis Qt 5.1 ensuite

    Posté par  . Évalué à 1.

    Pourquoi ?

    CC-BY-NC-SA

    • [^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 08 juillet 2013 à 15:34.

      Car Qt 4 propose je ne sais plus trop quoi en rapport à X11 dont les devs de LXDE ont besoin, qui a été supprimé dans Qt 5 et qui sera réintégré dans Qt 5.1.
      De plus l'idée de départ est de migrer le bureau vers un toolkit récent (question de durée de maintenance j'imagine), alors autant passer à la dernière version du toolkit.

      C'est expliqué dans un article du blog de LXDE mais je n'arrive pas à y accéder actuellement.

    • [^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite

      Posté par  . Évalué à 3.

      Probablement parce que développer quelque-chose sur une librairie stable est une bonne idée..
      Et si je me souviens bien Qt5 est censé être source compatible avec Qt4, donc pourquoi pas?

      • [^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite

        Posté par  . Évalué à 3.

        Et si je me souviens bien Qt5 est censé être source compatible avec Qt4, donc pourquoi pas?

        Peut être source comptabible (et l'est dans beaucoup de cas) mais quelques détails font qu'il ne suffit pas de compilé avec qt5 pour que ça marche.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite

        Posté par  . Évalué à 1. Dernière modification le 08 juillet 2013 à 17:52.

        Probablement parce que développer quelque-chose sur une librairie stable est une bonne idée..

        Pourquoi ne pas miser tout de suite sur qt5, en jouant sur le temps de développement des deux parties ?

        CC-BY-NC-SA

        • [^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite

          Posté par  . Évalué à 9. Dernière modification le 08 juillet 2013 à 18:39.

          C'est expliqué sur le blog qui est toujours directement inaccessible. Vive les caches !

          The version of Qt supported now is Qt 4. I’m going to skip Qt 5 and wait for Qt 5.1. Qt4 and Qt5 are compatible in many areas and porting to Qt5 should be easy in most of the cases. Unfortunately, this is not the case when you use X11-related stuff. Qt 5 removed many X11-related APIs and there are no direct equivalent methods. So the porting is not painless for desktop environments. In addition, some freedesktop.org specs are designed to work with X11 only, such as the EWMH/NETWM spec and Xsettings spec. To port to Wayland, these problems need to be solved first. Gnome and KDE guys will fix them so we can just wait. Then why Qt 5.1? Because Qt 5.1 added back the once-removed X11-related APIs. So porting from Qt 4 to Qt 5.1 should be the most smooth path. It takes time for distros to adopt Qt 5.1, though.

          Cela répondra peut-être même à guid.

          The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

  • # uniformisation?

    Posté par  . Évalué à 4.

    Y'a pas longtemps, on lisait que Webkit était en passe d'éliminer la concurrence Libre, et que ce n'était pas forcément une bonne nouvelle.

    Aujourd'hui, Qt (oui, bon: QtGui, mais mes doigts ont la flemme!) est en train d'éliminer progressivement Gtk. Est-ce une bonne nouvelle?

    Les EFL n'ont pas encore véritablement percé. Gtk est en perte de vitesse. Les autres bibliothèques ont des "parts de marché" anecdotique. Nous dirigeons-nous vers un écosystème Libre très uniforme avec un framework Qt omniprésent et les autres qui se partagent des miettes?

    Devrait-on s'en inquiéter?
    Si Qt devient sans concurrence, allons-nous voir une multiplication des bibliothèques sous licence commerciale et un ralentissement de la version Libre?

    Quel est l'avenir des bindings pour OCaml??

    Vous avez 4h. Moi je vais prendre ma douche.

    (Oui, ce commentaire n'avait pour seul but que de lancer un troll totalement H.S. sur OCaml et vous faire savoir que je suis propre)

    • [^] # Re: uniformisation?

      Posté par  . Évalué à 4.

      (Oui, ce commentaire n'avait pour seul but que de lancer un troll totalement H.S. sur OCaml et vous faire savoir que je suis propre)

      Si t'es propre, pourquoi vas tu prendre une douche ?

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

Suivre le flux des commentaires

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