Journal GTK+3/Win32 : cherche aide/mainteneur

Posté par (page perso) . Licence CC by-sa
Tags :
26
6
juin
2014

Cher journal,

Comme tu t'en souviens peut-être, je m'occupais jusqu'à récemment du port Win32 du toolkit GTK+3.

Cependant, les choses de la vie sont ce qu'elles sont, et il faut bien se rendre à l'évidence : je n'ai plus le temps, et il est important que quelqu'un s'en occupe étant donné que l'écart entre la dernière version publiée (3.6) et la dernière release upstream (3.12) s'accroît de jour en jour.

J'ai également écrit un post de blog en anglais pour expliquer la situation.

Je sais que tu n'es que mon confident, cher journal, mais j'espère cependant que quelqu'un te lira et réagira ;-).

  • # job

    Posté par . Évalué à 10.

    C'est hallucinant qu'un toolkit aussi important que GTK+3/Win32 n'ai pas une équipe de mainteneur payée pour faire ce boulot.

    Ou alors, ce port n'est finalement pas si important, et le darwinisme du logiciel libre fait qu'il doit maintenant disparaitre au profit de Qt /o\

    • [^] # Re: job

      Posté par (page perso) . Évalué à 4.

      C'est hallucinant qu'un toolkit aussi important que GTK+3/Win32 n'ai pas une équipe de mainteneur payée pour faire ce boulot.

      La réalité.

      Ou alors, ce port n'est finalement pas si important, et le darwinisme du logiciel libre fait qu'il doit maintenant disparaitre au profit de Qt /o\

      :-D :-(

    • [^] # Re: job

      Posté par (page perso) . Évalué à 8.

      C'est hallucinant qu'un toolkit aussi important que GTK+3/Win32 n'ai pas une équipe de mainteneur payée pour faire ce boulot.

      Bah, c'est à dire que comme pour pas mal de logiciels libres, les développeurs principaux n'utilisent pas le système d'exploitation Microsoft Windows, ne l'ont peut-être sur aucun de leurs ordinateurs, et ne se sentent pas concernés par l'effort de portage au point d'en faire l'acquisition et de travailler à cette tâche.

      • [^] # Re: job

        Posté par (page perso) . Évalué à 5.

        J'imagine que des sponsors de GNOME comme Red Hat ou Canonical ne désirent pas employer quelqu'un pour maintenir la version Windows. Celle-ci est utile à la communauté, l'idéal comme d'hab serait de parvenir à valoriser cela en $ trébuchants pour justifier un emploi.

        Peut être que des logiciels utilisateurs d'un toolkit devraient se considérer redevables (éthiquement bien sûr) de rétrocéder une partie, même faible, de leur donations au toolkit, et si tant est que le logiciel soit cross-platform, il serait alors logique que cette contribution s'applique aux efforts de portage.

        Mais comme ces considérations ne changeront rien au monde, il nous faut surtout un commercial de génie

        • [^] # Re: job

          Posté par (page perso) . Évalué à 10.

          Il faudrait surtout que GTK de façon générale recommence à envoyer du rêve, c'est triste mais on est un peu loin de l'époque où une appli en GTK était de fait cool et sexy, où on s'extasiait devant les plus beaux thèmes pour gtk. L'époque aussi où GTK était incontestablement le vrai toolkit natif de Linux. Maintenant les gens n'ont plus que Qt à la bouche, qui pourtant a l'énorme inconvénient d'être écrit en c++, ce qui rend les bindings vers les autres langages nettement plus compliqués.

          • [^] # Re: job

            Posté par (page perso) . Évalué à 6.

            Il faudrait surtout que GTK de façon générale recommence à envoyer du rêve

            Moi ce qui à l'époque m'avait fait tripper, c'était Broadway. Et effectivement, ça y est ça marche, on pourrait faire fonctionner GIMP-LibreOffice-etc en cloud avec ça. Il fait juste le polir, notamment pour supporter l'authentification et le multi-session.

            Qt à la bouche, qui pourtant a l'énorme inconvénient d'être écrit en c++, ce qui rend les bindings vers les autres langages nettement plus compliqués.

            Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.

            • [^] # Re: job

              Posté par (page perso) . Évalué à 3.

              Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.

              On peut depuis longtemps faire du Qt avec python. Et j'ai des applis qui tournent un Qt + ruby et ça marche bien (très sympa pour prototyper d'ailleurs)
              Après, certes pas de Vala (mais bon, entre c++11, python et ruby…) et pour PHP, ben heu, comment dire…

              Ok c'est pas forcément comme si c'était en C, mais faut voir aussi qu'avoir un toolkit en C n'est pas forcément ce qui donne envie de l'utiliser non plus.

              • [^] # Re: job

                Posté par . Évalué à 3.

                On peut depuis longtemps faire du Qt avec python.

                J'ai jamais compris pourquoi il y a 2 bindings python ni comment choisir entre l'un et l'autre.

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

                • [^] # Re: job

                  Posté par (page perso) . Évalué à 3.

                  J'ai jamais compris pourquoi il y a 2 bindings python ni comment choisir entre l'un et l'autre.

                  Parce qu'ils n'ont pas la même licence ni le même propriétaire du code.

                  « 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: job

                    Posté par . Évalué à 3.

                    Ouai mais grosso modo on s'en fout de ça, qu'est ce qui fonctionnellement va changer de l'un à l'autre ? Des querelles de clochets c'est bien mais quand on veut faire un choix, on prend le nom le plus joli ?

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

                    • [^] # Re: job

                      Posté par (page perso) . Évalué à 3.

                      Ouai mais grosso modo on s'en fout de ça

                      Non, on ne s'en fout pas. Si tu veux faire autre chose que du GPL, tu n'as déjà plus le choix.

                      mais quand on veut faire un choix, on prend le nom le plus joli ?

                      C'est valable pour n'importe quel toolkit. Si tu t'en fout vraiment tu tire à pile ou face, sinon tu fais 2-3 requêtes Google. Et si tu n'as pas l'impression que l'un est plus mauvais que l'autre. C'est qu'il n'y a pas de différence fondamentales et que tu ne ferra pas vraiment un mauvais choix.

                      « 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: job

                  Posté par (page perso) . Évalué à 2.

                  Si tu fais du Qt 5, le problème est plus simple : PySide ne fait que du Qt 4.

                  Sinon, je n'ai jamais utilisé PySide, uniquement PyQt et ça marche plutôt pas mal. En revanche, j'ai eu des bugs inexpliqués (l'application meurt, parfois avec une stacktrace C++) et impossibles à corriger (de façon totalement aléatoire et dans la partie C de Python ou C++ de Qt), qui ont à peu près disparu avec les dernières mises à jour.

        • [^] # Re: job

          Posté par (page perso) . Évalué à 1.

          J'imagine que des sponsors de GNOME comme Red Hat ou Canonical ne désirent pas employer quelqu'un pour maintenir la version Windows.

          Effectivement, ils n'y ont pas d'intérêt direct.

          rétrocéder une partie, même faible, de leur donations au toolkit

          Ce serait effectivement bien ; dans la pratique ça marche plutôt à sens unique, l'application utilise GTK+ et quand ce dernier ne fonctionne plus assez bien à son goût, elle migre vers un autre framework (Qt p.ex.) plutôt que de contribuer. Et une application de moins, ça signifie moins d'intérêt de la part des devs coeur, donc la qualité baisse encore… c'est un cercle vicieux.

    • [^] # Re: job

      Posté par . Évalué à 3.

      Important sous linux, mais sorti du monde linux ya pas grand chose qui l'utilise, donc ca a rien d'etonnant.

      Un peu comme le port macosx qui necessite (necessitait?) X, foutait en l'air tous les raccourcis claviers et mettait la barre de menu dans la fenetre.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: job

        Posté par (page perso) . Évalué à 2.

        Un peu comme le port macosx qui necessite (necessitait?) X

        Nécessitait.

  • # Oups!

    Posté par . Évalué à 2.

    The connection was reset

    The connection to the server was reset while the page was loading.

    Effet LinuxFr ?

  • # conditions de travail

    Posté par (page perso) . Évalué à 1.

    Hello

    Maintenir je me vois mal, mais aider pourquoi pas.
    Cela dit je pense que pas mal ici sont rebutés par le fait que windows soit necessaire, licence légale oblige.
    L'usage de ReactOS est il une option viable pour donner un coup de main ?

    • [^] # Re: conditions de travail

      Posté par (page perso) . Évalué à 2.

      Hello Vincent,

      GTK+ ne marche pas bien dans ReactOS, car le support des polices via Cairo y est cassé. J'ai identifié le problème la semaine dernière et commencé un patch, mais ça m'a pris des heures, et au final j'ai pas pu terminer avant que mon travail me "remange" mon cerveau. Mes découvertes sont dispo pour qui pense avancer avec.

      Sinon au pire, il y a Wine.

    • [^] # Re: conditions de travail

      Posté par (page perso) . Évalué à 5.

      Re vincent, j'ai du nouveau,

      Suite à ton comm, j'ai mis grand un coup ; je viens de finir le patch ReactOS qui y fait fonctionner GTK+ (2 et 3) :
      https://jira.reactos.org/browse/CORE-8306

      Je regarde si on peut builder avec aussi ; ce qui nous permettrait de ne plus dépendre du "Win32" commercial pour au moins le workflow basique .

  • # Une bouteille à la mer

    Posté par . Évalué à 2.

    Cher Tarnyko,

    Je découvre cette page légèrement vieillissante mais qui malgré tout est probablement encore d'actualité.

    J'ai fait la découverte de ta (on tutoie toujours son journal intime) connaissance sur ce magnifique post. Quelle ne fut pas ma surprise à l'époque de découvrir que quelqu'un d'autre que moi s'intéressait à GTK3 sous Windows. A l'époque, déplorant que personne ne fournisse des binaires, je m'en occupais moi-même avec un succès plutôt honorable dont je t'avais fait part.

    Cependant, je constate que mes craintes étaient justifiées et ton message me confirme que j'ai bien fait de ne pas abandonner mon script qui compile toujours la dernière version de gtk+ (3.12).

    Sache que de mon coté, je suis disponible pour fournir des paquets à jour. Il faudra simplement m'expliquer comment créer les paquets pour chaque librairie. Par contre, fournir une aide pour corriger les très nombreux (si, si !!!) bugs (mineurs) sous Windows est une autre affaire. Généralement, trouver comment corriger un de ces bugs me prend au minimum une demi-journée jusqu'à plus pour un résultat qui peut ressembler à du bricolage et que j'abandonne.

    Par contre, je n'ai pas réessayé depuis si la librairie compile sous Win64 depuis MinGW.

    Affaire à suivre…

    • [^] # Re: Une bouteille à la mer

      Posté par (page perso) . Évalué à 1.

      Hello Bansan,

      Je te remets !

      Il faudra simplement m'expliquer comment créer les paquets pour chaque librairie.

      Les paquets sont "assemblés", un peu de manière manuelle, via des scripts disposés sur la machine de build chez GNOME. Je vais essayer de te les récupérer, mais avec le temps libre dont je "dispose" je m'engage pas sur le timing.

      Par contre, fournir une aide pour corriger les très nombreux (si, si !!!) bugs (mineurs) sous Windows est une autre affaire.

      Bien d'accord. Perso mon principal problème était que l'entretien du build system devenant de plus en plus compliqué, et que par ailleurs les bugs s'accumulant, mon temps libre devenant plus réduit, le jeu n'en valait plus la chandelle.

      Généralement, trouver comment corriger un de ces bugs me prend au minimum une demi-journée

      Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).

      Par contre, je n'ai pas réessayé depuis si la librairie compile sous Win64 depuis MinGW.

      Ca fonctionne. Il faut utiliser MinGW64.

Suivre le flux des commentaires

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