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 Guillaume Denry (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 Kekun (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 zebra3 . Évalué à -2.
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 claudex . Évalué à 4.
Ç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 Guillaume Denry (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 Philippe F (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 téthis . Évalué à 10. Dernière modification le 06 juillet 2013 à 21:02.
(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 xcomcmdr . Évalué à 10. Dernière modification le 06 juillet 2013 à 23:57.
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 Atem18 (site web personnel) . Évalué à 6.
C'est aussi le cas pour les extensions de Gnome 3. On dirait Firefox et ses incompatibilités entre les versions…
# subsurface
Posté par EdB . É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 Spyhawk . Évalué à 10.
s/Linux/Linus/
De rien.
[^] # Re: subsurface
Posté par EdB . Évalué à 2.
Et en plus j'y ai pensé en rédigeant
[^] # Re: subsurface
Posté par deasy . Évalué à 1.
Tu peux donner une référence qui parle de ça? j'ai rien vu sur le lien.
[^] # Re: subsurface
Posté par claudex . Évalué à 10.
https://github.com/torvalds/subsurface
« 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 EdB . É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 deasy . É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.
[^] # Re: subsurface
Posté par Gilles G. . Évalué à 4.
L'intérêt principal c'est simplement le cross-platform.
Et Il y a d'autres raisons listées dans ce post:
https://plus.google.com/105872806106213007611/posts/MwiTc3cHKgi
[^] # Re: subsurface
Posté par deasy . Évalué à 2.
Merci !
# TortoiseHG aussi
Posté par Philippe F (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 Albert_ . É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 David Demelier (site web personnel) . Évalué à 8.
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 liberforce (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 Alex . Évalué à 7.
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 Albert_ . É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 reno . É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 Kekun (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 Guillaume Denry (site web personnel) . Évalué à 7.
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 liberforce (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 Guillaume Denry (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 Philippe F (site web personnel) . Évalué à 7.
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 woprandi . É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 Michaël (site web personnel) . Évalué à 2.
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 Happy-Tux . Évalué à 1.
Pourquoi ?
CC-BY-NC-SA
[^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite
Posté par Kekun (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 reno . É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 claudex . Évalué à 3.
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 Guillaume Denry (site web personnel) . Évalué à 2.
Du genre ? (la réponse m'intéresse vraiment, on a une grosse appli en Qt au boulot et je m'interroge sur l'opportunité de la migrer en Qt 5)
[^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite
Posté par med . Évalué à 3.
Je me souviens d'un blog de Martin Graesslin, le développeur principal de kwin, disant en somme que ça marche tout seul dans 99% des cas. Et que lui, manque de chance, il tombait dans le 1% parce que pour faire un gestionnaire de fenêtre ça tape précisément dans ce qui n'est pas compatible. J'imagine donc que pour une appli de bureau classique ça devrait être relativement aisé de faire le portage.
[^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite
Posté par claudex . Évalué à 4.
Je te conseille le wiki du projet Qt http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5 Et si tu veux un exemple, Qtcreator fonctionne à la fois sur Qt 4.8.4 et Qt5.
« 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 Happy-Tux . Évalué à 1. Dernière modification le 08 juillet 2013 à 17:52.
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 téthis . É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 !
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
[^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite
Posté par Happy-Tux . Évalué à 1.
Merci :)
CC-BY-NC-SA
# uniformisation?
Posté par Maclag . É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 xcomcmdr . Évalué à 4.
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.