Journal GTK+ Made Qt : une bonne idée pour KDE

Posté par  (site web personnel) .
Étiquettes : aucune
17
15
jan.
2010
Bonjour,

Ayant l'habitude de suivre le Planet KDE, je suis tombé sur un billet particulièrement intéressant : GTK+ made Qt.

L'auteur de ce billet propose de recréer une bibliothèque GTK+, mais utilisant au maximum Qt. Telle qu'il la présente, elle n'est pas binairement compatible, mais uniquement du point de vue des sources. Il a déjà des exemples qui tournent, et le travail semble correct.

Par contre, cette bibliothèque n'est pas encore du tout propre, et n'est qu'une ébauche. Toutes les vérifications faites par GTK ne sont pas faites, plein de trucs ne vont pas, etc.

Néanmoins, c'est une idée qui ne peut qu'être applaudie des deux mains, et est peut-être le futur projet libre de l'année. En effet, les promesses de ce genre de bibliothèque sont énormes : enfin des applications GTK parfaitement intégrées à Qt.

La méthode n'est peut-être pas la plus simple (le plus simple aurait été un backend GTK, comme il en existe pour Windows et Mac), mais il faut avouer que l'idée est séduisante, surtout si tout le boulot se fait à la compilation.

Par contre, du côté technique, ça promet d'être difficile. En effet, le C est très facilement utilisé depuis le C++, mais l'inverse est déjà nettement moins facile.

En tous cas, ce binding inattendu est vraiment très prometteur, et on ne peut qu'encourager l'auteur. Si vous connaissez Qt et GTK+, c'est un bon projet auquel participer, déjà rien que pour montrer que ça intéresse des gens.

Parlez-en, une nouvelle aire d'intégration commence peut-être !

Toutes mes félicitations à son auteur.
  • # Un mur en approche

    Posté par  . Évalué à 6.

    « Il a déjà des exemples qui tournent, et le travail semble correct. »

    Il a des exemples *triviaux* sur un code loin, très loin (selon ses propos), d'être propre.

    Chouette...

    Ça va être la fête quand il faudra tout mettre sous l'API Gtk/Gdk. D'ailleurs, il commence mal son encapsulation :
    QWidget *gtk_window_new(int) { return new QWidget(); }

    Il va falloir mettre des pointeurs sur des QWidget dans un code censé utiliser Gtk ? Amusant.


    Personnellement, je pense que ce projet va donner lieu à plein de bidouilles pour un résultat médiocre.


    « ...est peut-être le futur projet libre de l'année »

    C'est surtout qu'il ne passera probablement pas l'année :-/


    « Toutes mes félicitations à son auteur. »

    Non, franchement pas.
  • # Toujours dans le même sens

    Posté par  . Évalué à 3.

    Encore une fois c'est Qt/KDE qui bosse sur l'intégration de GTK.

    On voit souvent des postes du type : « How make Qt looks like GTK » mais rarement l'inverse, et ça me saoul. Si je pouvais intégrer mes application GTK dans un environnement ou j'ai principalement du Qt (Un OpenBox où mes 4 uniques applications graphiques sont en Qt) j'utiliserai des appli GTK.

    Sinon, on remarque aussi que tout ça n'est qu'une histoire d'intégrisme :þ

    Comme on est trolldi : GTK suxx, Qt rox ! (ceci est purement trollesque et ne reflète en rien la réelle pensée de l'auteur).
    • [^] # Re: Toujours dans le même sens

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

      Non, là, contrairement à ce que l'auteur explique dans cette dépêche, c'est une implémentation de GTK+ en Qt, donc pour avoir des applications GTK+ qui affichent en Qt.
      • [^] # Re: Toujours dans le même sens

        Posté par  . Évalué à 1.

        C'est ce que j'ai pas dit :þ

        Non, je répondais pas directement au journal en fait, je disais juste ce que je ressentais vis à vis de l'intégration des 2 framework.
        • [^] # Re: Toujours dans le même sens

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

          sous Gnome, je n'ai aucun souci avec des application Qt, c'est bien que cela marche dans un sens au moins :-)
          VLC est passé à Qt, ce qui est bien, ça fonctionne bien avec Gnome en tout cas. N'est-ce-pas un simple souci KDE ? (il est encore 'dredi).
          • [^] # Re: Toujours dans le même sens

            Posté par  . Évalué à 10.

            Oui, les applications Qt reprennent le style de GTK+, de la même façon que les applis Qt sous Windows reprennent le style Windows.

            Mais l'inverse n'est pas possible, sauf à utiliser gtk-qt-engine, qui n'est pas fameux, et pas disponible par défaut dans GTK.

            C'est ce que je déplore aussi, pourquoi les gens de GTK ne s'occupent pas de reprendre le style Qt quand des applis GTK sont lancés sur KDE ?
            Bon évidemment, c'est plus facile à dire qu'à faire, mais je crois que ça plairait à pas mal de gens d'avoir un Firefox ou autres avec un rendu Qt.

            Tout ceci prouve bien que Qt > GTK+ au final.
            • [^] # Re: Toujours dans le même sens

              Posté par  . Évalué à -1.

              Tout ceci prouve bien que Qt > GTK+ au final.

              Non. Si personne ne prend la peine de faire ça, ça prouve juste qu'il y a suffisamment d'applis en GTK pour ne pas avoir besoin d'applis en Qt, et qu'on peut avoir des environnements full-GTK.

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

              • [^] # Re: Toujours dans le même sens

                Posté par  . Évalué à 4.

                C'est possible mais il y a quand même quelques applications importantes en Qt qui n'ont pas forcément d'équivalent (Lyx, VLC, ...)

                « 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: Toujours dans le même sens

                Posté par  . Évalué à 5.

                Euh justement: intégrer une appli QT est très facile parce qu'on peut dire à QT d'utiliser GTK pour le rendu... mais pas l'inverse, or c'est de cela qu'on parle.
                • [^] # Re: Toujours dans le même sens

                  Posté par  . Évalué à 3.

                  Moi j'arrive pas à intégré QT.

                  Par contre Qt là, oui.

                  /me →[]
                • [^] # Re: Toujours dans le même sens

                  Posté par  . Évalué à 10.

                  Faut relativiser, derrière Qt, il y a une société (d'une taille fort respectable), des développeurs/testeurs/écrivains techniques à temps pleins etc ... En comparaison, Gtk+ est bien plus mal loti, la majorité des développeurs Gtk+ sont des développeurs GNOME.
                  Très peu de personnes sont payés pour travailler à temps plein sur Gtk+ (à ma connaissance, aucun actuellement).

                  QGtkStyle a été écrit courant 2008 et intégré dans Qt 4.5 (printemps 2009), c'est relativement récent l'intégration visuelle digne de ce nom dans un environnement basé Gtk+.
                  Puis, il manque pas mal de choses pour qu'une application Qt s'intégre parfaitement, par exemple, pouvoir utiliser les jeux d'icônes standard (c'est prévu pour Qt 4.7 il me semble), la disposition des labels dans les menus etc ...
                  Certes, de gros efforts ont été mené pour faciliter l'intégration de Qt dans les bureaux natifs (pas que GNOME, mais également Windows et OS X) mais principalement de la part de Nokia/Qt, pas des développeurs KDE (non affilié à Nokia s'entends).

                  C'est un peu trop facile de taper sur un Gtk+ qui est très loin d'avoir les mêmes ressources que Qt.

                  ----

                  Pour revenir sur le sujet du journal, j'ai l'impression qu'on n'a pas compris l'objectif de Jonathan Thelin. D'abord Jonathan Thelin est un expert Qt reconnu (auteur du tutoriel indépendant de Qt, du bouquin "Foundations of Qt Development" *LE* meilleur bouquin d'initiation à Qt) et spécialiste de l'embarqué.
                  C'est avant tout une expérimentation, pas un projet bien défini. Plutôt que de permettre l'intégration des application Gtk+ à un environnement Qt (pas très réaliste, un moteur de rendu à gtk-qt-engine aurait plus approprié), ce serait surtout un kit de transition pour porter des applications Gtk+ vers un environnement Qt (sans Gtk+, sans X11 etc ...).
                  L'un des axes de développement de Qt est l'embarqué notamment la téléphonie mobile, entre Maemo qui va passer d'un environnement basé sur GNOME Mobile vers un environnement basé sur Qt.
                  J'ai bien souligné que Jonathan Thelin était un spécialiste de l'embarqué, maintenant à vous d'en tirer les conclusions sur l'intérêt de cette expérimentation.
                  • [^] # Re: Toujours dans le même sens

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

                    C'est un peu trop facile de taper sur un Gtk+ qui est très loin d'avoir les mêmes ressources que Qt.

                    Tu parles des causes, le reste des commentaires parlent du résultat.

                    Perso, je m'en fou de la cause, c'est le problème de l'équipe GTK+ si ils n'ont pas réussi (ou voulu) à trouver un financement.

                    Moi, je constate juste que Qt fait un effort pour offrir un SDK qui me permet d'offrir une UI homogène aux utilisateurs KDE, Gnome, Windows, Mac OS X (et autres)., et que côté GTK l'UI est homogène que pour les utilisateurs Gnome (bon, ajoutons Windows à moitié, puisque que GTK n'utilise pas les boites de dialogue native, et il faut mettre un thème GTK-Wimp. GTK sous Mac j'avoue ne pas savoir)
                    Resultat : Qt 4 (+ les mobiles), GTK 1.5 (modulo Mac), résultat net.

                    C'est aussi une différence de philosophie : l'un fait énormément pour s'intégrer à l'OS, l'autre fait "juste" le nécessaire pour que ça compile sur un OS donné qui n'est pas Gnome.

                    Bref, je comprend la cause, mais ça n'empêche pas que ce qui compte, c'est le résultat, le fait de ne pas avoir x développeurs sur cette partie est un "choix" (avec les contraintes) des développeurs, l'un a su trouver un modèle qui permet le développement, pas l'autre. Je suis bien conscient que ce n'est pas facile (WxWidgets est dans la même situation, il n'évolue plus), que Qt a eu la "chance" d'avoir un gros acheteur intéressé, mais ça fait aussi partie des conséquences des choix faits (est-ce que le copyright de GTK pourrai être revendu à une grosse boite? Il me semble que non, chaque contributeur gardant son copyright, mais pour Qt si, c'était un choix de l'entreprise derrière...)

                    Et ensuite, finalement, il ne reste peut-être de la place que pour un toolkit graphique multi-OS, et GTK redeviendra alors peut-être que le tookit natif de Gnome... Et ceux souhaitant que l'utilisateur ai une UI homogène choisiront Qt, la seule solution réellement bonne pour les gens qui veulent que l'utilisateur ai son UI et pas celle d'un autre OS que celui de l'utilisateur.
                    • [^] # Re: Toujours dans le même sens

                      Posté par  . Évalué à 7.

                      Différence de philosophie, c'est bien vite.
                      Gtk+ est un projet communautaire maintenu par des volontaires, Qt était un framework propriétaire qui s'est progressivement ouvert mais qui est très largement maintenu par une seule société. Dès le départ, le modèle de développement/économique n'était pas le même (bazar vs cathédrale).
                      Oui, Nokia/Qt fait plus d'efforts que Gtk+ mais ils ont plus de moyens, ce n'est pas de la 'mauvaise volonté' de la part des développeurs Gtk+.


                      Dans ce fil, on donne l'impression que KDE fait des efforts pour s'intégrer dans un environnement GNOME et que ce n'est pas réciproque.
                      KDE != Qt, KDE est un simple "utilisateur" de Qt, KDE ne participe peu (ou pas) au développement de Qt (à l'exception de Phonon), KDE n'a rien à voir avec les efforts d'intégration mené par Nokia. Une application KDE ne s'intégrera pas mieux à GNOME qu'une application GNOME à KDE, par défaut une application KDE n'utilise pas le thème par défaut de Gtk+ (donc pas de QGtkStyle).
                      Hormis le look, une application Qt n'est pas mieux intégré dans un environnement KDE que dans un environnement GNOME. Quant au feel d'une application Qt "vanilla", sans travail d'intégration, il sera tout aussi étranger sur bureau KDE que sur GNOME.

                      Si on commence à regarder sur FreeDesktop, on constate que GNOME fait beaucoup plus d'efforts que KDE pour favoriser l'interopérabilité en étant force de proposition, en implémentant les specs de façon la plus neutre possible (dbus, xdg, *Kit, etc...).
                      Qt fasse plus d'efforts certes, mais KDE bof bof.
                      • [^] # Re: Toujours dans le même sens

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

                        Oui, Nokia/Qt fait plus d'efforts que Gtk+ mais ils ont plus de moyens, ce n'est pas de la 'mauvaise volonté' de la part des développeurs Gtk+.

                        Quand on veut arriver à une cible donnée, il faut faire des choix. De ce que je vois, les développeurs GTK ne sont pas prêts à faire les choix nécessaires, ce n'est certes pas forcement de la "mauvaise volonté", mais ce n'est pas non plus la "volonté d'aller dans cette direction à tous prix et donc on cherche un moyen d'y arriver". Encore une fois, je regarde le résultat, ce qui est fait (ou ce qui va être fait : je n'ai jamais lu que GTK allait mettre des moyens dans cette direction même dans le futur)


                        Dans ce fil, on donne l'impression que KDE fait des efforts pour s'intégrer dans un environnement GNOME et que ce n'est pas réciproque.

                        Je n'ai pas l'impression qu'on parle de KDE.
                        On parle de Qt qui s'intègre mieux a KDE et Gnome que GTK, qui ne s'intègre bien qu'à Gnome, et on lance la pierre à GTK.
                        Ou as-tu vu "impression que KDE fait des efforts " --> Qt fait des efforts, on parle de Qt!

                        Quant au feel d'une application Qt "vanilla", sans travail d'intégration, il sera tout aussi étranger sur bureau KDE que sur GNOME.

                        Permet-moi d'en douter : je travaillais avant avec WxWidgets (donc GTK en dessous), mon appli allait très bien sous Gnome et horrible sous KDE, maintenant, je passe à Qt, et ça passe très bien sous Gnome, l'intégration Qt a l'air d'être relativement aléatoire suivant la distro, mais ce n'est pas Qt qui pose problème, "juste" la façon dont la distro l'a intégré : sur je ne sais plus lesquelles de distro, faudrait que je reteste, je développe en Qt sans rien faire de plus, et quand je lance l'appli elle a le style Gnome (pour les autres distros, si je me souviens bien, il faut que je force le thème, c'est juste un paramètre à ajouter à la ligne de commande lancée).
                        De la même manière, si je demande à GTK d'ouvrir la boite de dialogue d'ouverture de fichier, GTK affiche sa boite quel que soit l'OS, alors que Qt communique avec l'OS pour afficher la boite de dialogue de l'OS.
                        Bref, niveau intégration, ça va avec Qt mieux qu'avec GTK.

                        Hormis le look, une application Qt n'est pas mieux intégré dans un environnement KDE que dans un environnement GNOME

                        A quoi penses-tu? Parce que Qt a pas mal de fonctions qui lissent les différences quand même...

                        Qt fasse plus d'efforts certes, mais KDE bof bof.

                        On parle de Qt depuis le début : Qt vs GTK. On ne parle pas de d'environnements de bureau, mais de toolkits! Pas la peine de tout mélanger en y ajoutant les gestionnaires de bureaux dans la partie "dev", laissons dans la partie "UI cible" : le bilan est la, Qt gère Gnome/KDE/Mac OS X/Windows, GTK gère Gnome et c'est tout.
                      • [^] # Re: Toujours dans le même sens

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

                        Je nourris le troll:
                        Peut importe qui développe et comment c'est développer, quand on regarde le résultat final, il semble que l'un est meilleur que l'autre. En plus tous les deux sont libre.


                        Quelque précisions:
                        - Qt permet d'utiliser le jeux d'icône standard depuis Qt 4.6 http://doc.trolltech.com/4.6/qicon.html#fromTheme
                        - La disposition des labels et des icônes dans les menu Qt suit les préférences que KDE ou de GNOME en fonction du bureau
                        - Les développeur Gtk+ principaux sont tout de même payé pour leur travail par des entreprises comme RedHat ou Novell. (Ils sont certes moins nombreux que les développeurs Qt)
                    • [^] # Re: Toujours dans le même sens

                      Posté par  . Évalué à 1.

                      GTK sous Mac j'avoue ne pas savoir

                      Ca utilise x11, c'est une horreur, tu peux pas faire pire niveau integration, meme un windows dans vmware en seamless est mieux.

                      Ya l'air d'avoir un projet de port pour macos, mais c'est pas encore fini.
                      Ca avance cela dit, ya pas si longtemps que ca, c'etait x11 ou creve.
                    • [^] # Re: Toujours dans le même sens

                      Posté par  . Évalué à 0.

                      Tiens, toi qui est un fan de la libre détermination de chacun et de la culture du résultat, ne t'es-tu pas posé la question qui tue : peut-être que Qt n'intéresse presque personne, que ceux qui utilisent GTK n'en ont rien à foutre du look'n'feel sur les plateformes autres que Linux, et que si GTK s'intègre mal à Qt, on n'en a rien à foutre non plus ?

                      Franchement, là, tu fais moraliste à deux balles, quelque chose que tu dénonces dès que quelqu'un te fais le coup ... Si t'es pas content, code le. En attendant, moi et une bonne partie des utilisateurs sont très contents comme ça.
                  • [^] # Re: Toujours dans le même sens

                    Posté par  . Évalué à 9.

                    >> C'est un peu trop facile de taper sur un Gtk+ qui est très loin d'avoir les mêmes ressources que Qt.

                    GTK a le soutien de Novell, Sun... bref, les sociétés qui trouvaient que la GPL de Qt n'était pas assez libre pour faire du proprio. Ils préféraient la LGPL
                    • [^] # Re: Toujours dans le même sens

                      Posté par  . Évalué à -1.

                      Peut-être que c'est ironique, mais au cas où :

                      http://qt.nokia.com/about/news/lgpl-license-option-added-to-(...)
                      Qt est dispo sous LGPL depuis début 2009.
                      • [^] # Re: Toujours dans le même sens

                        Posté par  . Évalué à 3.

                        C'est vrai que GTK n'est sorti que fin 2009.

                        « 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: Toujours dans le même sens

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

                          Le monde change, pourquoi veux-tu continuer à juger un projet sur des raisons qui n'existent plus?

                          Je comprend pour un vieux projet qui a déjà du code écrit pour un toolkit, mais si je regarde maintenant pour un nouveau projet, je ne vois pas pourquoi je devrait prendre en compte un argument qui n'est plus valide : Qt est LGPL maintenant et GTK+ n'est pas intégré à KDE maintenant.
                          • [^] # Re: Toujours dans le même sens

                            Posté par  . Évalué à 2.

                            Tu es sûr de répondre à la bonne personne?

                            « 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: Toujours dans le même sens

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

            Ça marche, évidemment. Mais ça n'a pas la même apparence, ce qui est dommage.

            Mais soit dit en passant, l'uniformité de l'apparence des logiciels, si c'est très important, la majorité des gens s'en moquent éperdument, ou du moins, acceptent sans trop râler qu'elle ne soit à peu près inexistante. Il suffit de voir quelqu'un utiliser Windows Internet Explorer, Window Media Player, iTunes et Microsoft Office : rien n'a le même aspect.
            • [^] # Re: Toujours dans le même sens

              Posté par  . Évalué à 3.

              Mais il y a un minium d'estétisme. Un logiciel GTK sous KDE sans le gtk-qt-engine c'est très très moche.

              « 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: Toujours dans le même sens

                Posté par  . Évalué à 1.

                je plussoie! :)

                Il aurait pu créer un théme par défaut à la compilation, là dans l'état ce sont toutes les valeurs à zéro et c'est clairement moche!

                Donc que toutes les applis se ressemblent... pas nécessairement.
            • [^] # Re: Toujours dans le même sens

              Posté par  . Évalué à 1.

              Wine n'a pas encore implemente les themes ou il y a juste un debut pour avoir un aspect visuel un peu plus coherent et sinon c'est pas parceque les autres font de la m... que l'on doit les imiter. D'ailleurs tu aurais pu aussi parler de MacOS X sur le sujet ou Itunes (pour reprendre ton exemple) est aussi a cote de la plaque ce qui est surprenant vu Apple, une question d'histoire?
              • [^] # Re: Toujours dans le même sens

                Posté par  . Évalué à 1.

                en quoi itunes est a cote de la plaque vis a vis de macosx?

                Le seul truc dans son ui qui n'est pas "par defaut" c'est les scrollbars (et encore, a verifier, mais je serais surpris que ca ne soit pas juste un style de scrollbar).
                • [^] # Re: Toujours dans le même sens

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

                  Il y a aussi sa couleur en générale qui est différente. Il est bien plus clair, argenté.
                  • [^] # Re: Toujours dans le même sens

                    Posté par  . Évalué à 1.

                    Pour la couleur ca ressemble a s'y meprendre a la couleur "window frame color" d'interface builder avec un gradient.

                    'fin entre ca, et une utilisation du scroller fourni par cocoa, on est loin de "completement a cote de la plaque"...

                    Autant, vous m'auriez parle d'imovie ou idvd, j'aurais pas dit, mais la pour le coup...
    • [^] # Re: Toujours dans le même sens

      Posté par  . Évalué à -5.

      C'est peut-être aussi qu'un environnement full-GTK n'a besoin d'aucune application Qt, alors que l'inverse n'est pas forcément vrai ? Du coup, oui, KDE bosse sur l'intégration d'applis GTK, alors que GNOME n'en a pas besoin.

      Personnellement, je n'utilise aucune application en Qt, j'ai trouvé mon bonheur pour chaque besoin en GTK. Le seul point qui a manqué pendant des années, c'était la gravure de CD, mais maintenant que Brasero a intégré GNOME, plus besoin de Qt.

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

      • [^] # Re: Toujours dans le même sens

        Posté par  . Évalué à 3.

        Sauf qu'ils bossent dans les deux sens. Qt bosse pour avoir un rendu GTK des appli Qt et KDE bosse pour rendre les appli GTK sous KDE.

        « 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: Toujours dans le même sens

        Posté par  . Évalué à 6.

        J'ai pas de bureau full-Qt, full-GTK, full-win32, j'ai un OpenBox avec des applications que j'installe moi-même donc mon problème c'est que dès que j'ai une application GTK (récemment wicd), c'est pas intégré avec mon style Qt, les 2 ont un style différent et j'aime le style Qt, donc le QGTKStyle, très peu pour moi.

        Le jour où on pourra, dans une application comme GTKChTheme mettre : « style Qt » (comme dans QtConfig en fait), là je commencerai à regarder les appli GTK. À l'heure actuelle, j'utilise pas d'appli GTK, sauf pour tester et sauf quand y a rien d'autre.

        Encore une fois comme dit dans mon poste en haut : ça marche que dans un sens : Qt DOIT ressembler à GTK, et chez GTK, eux ils s'en foutent (y a qu'à voir : QGTKStyle, gtk-qt-engine, les postes sur les boards GNUx : « Make GTK looks like Qt » etc.).
  • # Quelle est sa superficie?

    Posté par  . Évalué à 10.

    Parlez-en, une nouvelle aire d'intégration commence peut-être !

    J'éspère que cette ère commencera le plus tôt possible!
  • # C'est compliqué c't'affaire.

    Posté par  . Évalué à -10.

    Pourquoi ne pas utiliser GTK pour toutes les applications graphiques ? C'est simple, efficace et ça rendrait homogène l'apparence de toutes les applications.


    Ah... on n'est déjà plus trolldi.

    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: C'est compliqué c't'affaire.

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

      Parce que certain veulent être productif ?

      désolé, c'était vendredi...
      • [^] # Design de l'application

        Posté par  . Évalué à -4.

        Bonjour,
        je peux me tromper mais wxWidgets continue d'évoluer et offre le look natif du système sur lequel on travaille (certes GTK+ sous linux). J'ai du mal à voir l'intérêt de GTK+ car la documentation est bien loin du niveau de celle de wxWidgets ou Qt. Certes Qt soutenu par une société tirera certainement mieux son épingle du jeu (et le fait déjà) que wxWidgets. Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.
        Lorsque je regarde les API (systèmes, machine virtuelle...) qui ont fonctionné ou fonctionne (java, C#), elles fonctionnent car elles offrent un même code pour tous les systèmes. Pourquoi wxWidets, Qt qui sont sur le même créneau sur les 3 principaux systèmes mais en natif donc plus performant n'ont pas su s'imposer j'ai un peu de mal à comprende (certainement le C++). En ce qui me concerne je trouve que le principal c'est la documentation puis la bibliothèque et à ce niveau j'ai toujours eu du mal avec GTK. Et ce n'est pas un troll :-)
        Bonne fin de journée

        PS à part GIMP de connu qui utilise GTK sur linux/windows, wxWidgets lui a Audacity, Amaya, CodeBlocks...mais visiblement cela ne suffit pas puisque j'ai l'impression que : Ouf VLC est passé en Qt :-)
        • [^] # Re: Design de l'application

          Posté par  . Évalué à 3.

          Pourquoi [...] Qt [...] n'ont pas su s'imposer

          Qt a quand même bien su s'imposer. Je suis pas sûr qu'il y ait autant d'applications (pour desktop, sinon ça sert à rien de comparer) fort distribuées en Java: http://qt.nokia.com/qt-in-use/target/qt-in-use/target/deskto(...) http://qt.nokia.com/qt-in-use

          « 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: Design de l'application

            Posté par  . Évalué à -4.

            Bonsoir,
            je parlais naturellement des applications hors KDE et hors linux, plutôt sur les applications sur Microsoft Windows, c'est à dire sur le système qui (hélas) est le plus utilisé sur des ordinateurs de bureau.
            Bonne soirée
            • [^] # Re: Design de l'application

              Posté par  . Évalué à 2.

              C'est vrai que Google Earth, VLC, Adobe Photoshop Album, Skype sont des applications KDE bien connues.

              « 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: Design de l'application

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

          mais wxWidgets continue d'évoluer et offre le look natif du système sur lequel on travaille

          Oui, j'aimai bien cette idée. Malheureusement l' "offre" n'a pas suivie. WxWidgets n'offre pas assez de choses par rapport à Qt, sans compter que le port Mac est à l'arrache (j'ai abandonné WxWidgets quand j'ai vu toutes les merdes graphiques sous Mac, et la version Cocoa n'est pas près d'être stable).

          WxWidgets était une bonne idée au départ, sur le principe je le préfère à Qt car Qt "copie" l'interface de l'OS hôte, mais n'utilise pas forcement le toolkit natif et c'est chiant (en plus d'être volumineux). Malheureusement, ça na pas suivit ensuite face au rouleau compresseur Qt qui offre bien plus de Widgets, d'aide à la construction du GUI.

          (certes GTK+ sous linux)

          Ce qui pose un problème, cf les autres commentaires : WxWidgets utilisant GTK+, il en prend les défauts donc pas d'intégration dans KDE. 1 point en moins.

          Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.

          Toi, tu n'as pas assez programmé en WxWidgets pour dire ça...
          • [^] # Re: Design de l'application

            Posté par  . Évalué à -2.

            >Toi, tu n'as pas assez programmé en WxWidgets pour dire ça...
            bien si mais pas forcément en Qt, et sauf erreur de ma part, celui qui a "repris" VLC programmait en Qt du coup le portable.
            Je suis d'accord sur le fait que l'avenir de wxWidgets est moins "rose" depuis que Qt est passé en LGPL car Qt offre plus de choses, et va plus vite car c'est développé par une entreprise+KDE aussi. Pour l'aide à la construction wxFormbuilder est pas trop mal (mais j'ai pas testé il est vrai du côté de Qt). Et le port de python pour Qt il est comment ?
  • # Design de l'application (en commentaire cette fois-ci)

    Posté par  . Évalué à -3.

    Bonjour et désolé pour le doublon,
    je peux me tromper mais wxWidgets continue d'évoluer et offre le look natif du système sur lequel on travaille (certes GTK+ sous linux). J'ai du mal à voir l'intérêt de GTK+ car la documentation est bien loin du niveau de celle de wxWidgets ou Qt. Certes Qt soutenu par une société tirera certainement mieux son épingle du jeu (et le fait déjà) que wxWidgets. Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.
    Lorsque je regarde les API (systèmes, machine virtuelle...) qui ont fonctionné ou fonctionne (java, C#), elles fonctionnent car elles offrent un même code pour tous les systèmes. Pourquoi wxWidets, Qt qui sont sur le même créneau sur les 3 principaux systèmes mais en natif donc plus performant n'ont pas su s'imposer j'ai un peu de mal à comprende (certainement le C++). En ce qui me concerne je trouve que le principal c'est la documentation puis la bibliothèque et à ce niveau j'ai toujours eu du mal avec GTK. Et ce n'est pas un troll :-)
    Bonne fin de journée

    PS à part GIMP de connu qui utilise GTK sur linux/windows, wxWidgets lui a Audacity, Amaya, CodeBlocks...mais visiblement cela ne suffit pas puisque j'ai l'impression que : Ouf VLC est passé en Qt :-)
    • [^] # Re: Design de l'application (en commentaire cette fois-ci)

      Posté par  . Évalué à 4.

      à part GIMP de connu qui utilise GTK sur linux/windows
      Pidgin, Inkscape, GVim pour ceux que j'ai utilisé

      En ce qui concerne la documentation de GTK c'est un reproche que j'ai vu plusieurs fois et que je comprend pas. Es ce que quelqu'un pourrait donner plus de détails sur ce qui ne va pas avec ?
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

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

  • # documentation GTK

    Posté par  . Évalué à 0.

    Bonsoir,
    C'est vrai que pour les applications certaines ont été depuis portées sur windows mais il y en a moins que wxWidgets je trouve on peut rajouter kicad, wxMaxima, digsby, filezilla....
    Pour la documentation GTK, j'avais essayé de rajouter des fonctionnalités à wxWidgets version linux, mais j'avais laissé tomber pour certaines car je trouvais qu'il n'y avait pas assez d'explications sur GTK (attention il s'agissait de faire des éléments un peu plus techniques que ceux de base qui existent déjà sur wxWidgets). Le plus simple serait de voir ce qu'il y a sur wxWidgets (doc+livre en pdf), je trouve que c'est beaucoup plus clair à tous niveaux. Les informations sont certainement là aussi sur GTK mais j'avais eu plus de mal à les trouver (sans parler des "cast" entre GDK, GTK...), plus simple sur wxWidgets (désolé c'est ce que j'utilise). Ce que j'avais testé sur Qt m'avait demandé aussi beaucoup moins de temps que pour la même chose sur GTK. J'avais le sentiment que la doc GTK c'était juste l'API sortie avec docoxygen. Voilà mon ressenti, pas forcément complètement objectif.
    A+
    • [^] # Re: documentation GTK

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

      La doc c'est un peu le soucis de tous les projets libres qui sont developpés par des benevoles. Comme c'est quand même bien pénible a ecrire (et a maintenir), on a tendance a faire l'impasse, ou à faire un truc bien pourri en doxygen. Alors que si ton chef te dit que ta doc est pourrie et que t'as un mois pour la relire et la completer, tu le fais, ou tu la refile à un stagiaire ou je ne sais quoi.

      C'est sur que gtk gagnerait pas mal à avoir une doc digne de ce nom. ALSA aussi d'ailleurs.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

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

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

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

Suivre le flux des commentaires

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