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 ckiller . É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 Tarnyko (site web personnel) . Évalué à 4.
La réalité.
:-D :-(
[^] # Re: job
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
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 saltimbanque (site web personnel) . É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 Troy McClure (site web personnel) . É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 Tarnyko (site web personnel) . Évalué à 6.
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.
Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.
[^] # Re: job
Posté par CrEv (site web personnel) . Évalué à 3.
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 barmic . Évalué à 3.
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 claudex . Évalué à 3.
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 barmic . É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 claudex . Évalué à 3.
Non, on ne s'en fout pas. Si tu veux faire autre chose que du GPL, tu n'as déjà plus le choix.
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 flan (site web personnel) . É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 Tarnyko (site web personnel) . Évalué à 1.
Effectivement, ils n'y ont pas d'intérêt direct.
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 groumly . É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 Tarnyko (site web personnel) . Évalué à 2.
Nécessitait.
# Oups!
Posté par Spack . Évalué à 2.
Effet LinuxFr ?
[^] # Re: Oups!
Posté par Tarnyko (site web personnel) . Évalué à 2.
Doit remarcher maintenant.
# conditions de travail
Posté par vincent LECOQ (site web personnel) . É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 Tarnyko (site web personnel) . É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 Tarnyko (site web personnel) . É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 .
[^] # Re: conditions de travail
Posté par vincent LECOQ (site web personnel) . Évalué à 2.
hey, voila une bonne nouvelle ;)
# Une bouteille à la mer
Posté par bansan . É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 Tarnyko (site web personnel) . Évalué à 1.
Hello Bansan,
Je te remets !
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.
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.
Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).
Ca fonctionne. Il faut utiliser MinGW64.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.