Tarnyko a écrit 421 commentaires

Impeccable, bon à savoir :-).

En attendant de s'y retrouver ; bons préparatifs !

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.

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 ^.

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.

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.

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.

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

Nécessitait.

Doit remarcher maintenant.

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 :-(

Hello nazcafan,

Le choix de cairo s'est imposé naturellement pour ce que tu cherchais a faire ?

Oui, car c'est d'une part une dépendance de Weston (donc susceptible d'être déjà installée sur les systèmes du public "cible" de wlmessage), et d'autre part je le connaissais bien pour avoir déjà bossé avec GTK+.

C'est un portage de xmessage ou bien tu es reparti d'une page blanche sans trop regarder comment le truc de base était fait ?

Page blanche, j'avoue (rougit). J'ignore si j'aurais pu réutiliser un peu ou beaucoup.

Salut, et merci pour tes encouragements,

Ça me semble pas forcement pertinent. Comment tu vas faire pour l'intégration du style?

Il n'y en aura pas, je pense. wlmessage gardera la même apparence partout.

Pourquoi ne pas faire une interface commune et 2 ou 3 backends (GTK 3.0/Qt et EFL) qui seront choisis au runtime?

Ça c'est une riche idée ! Et je pense que ça pourrait être un projet intéressant pour une personne désireuse de s'initier au monde des toolkits.
À titre personnel, je ne voulais pas le faire pour garder le côté "léger" du logiciel. Je vais sans doute finir par retirer la dépendance à la GLib p.ex. ; ça s'inscrit dans cette démarche.

Ne me fais pas dire ce que je n'ai pas dit :-).

Mais il est clair qu'ils n'ont pensé qu'à GNOME au moment de faire cette modification. Pour un toolkit/framework se voulant à une époque cross-plateforme, ça veut dire au mieux : "on a un boulot à faire sur GNOME, on y va en bourrins, si ça dérange quelqu'un il patchera derrière".

Le problème étant que les développeurs compétents ayant tous peu de temps, ils ont autant de chance de patcher que de switcher vers un toolkit concurrent qui ne leur fera pas le même coup à l'avenir…

C'est en fait l'application qui a été codée pour utiliser GtkHeaderBar ; ce nouveau widget remplace la barre de titre habituelle et jouant avec des "hints" du gestionnaire de fenêtres.

Le problème est effectivement que ça n'a pas de sens sous les DE non-GNOME, ni sous Win32, ni sous OS X. Or, depuis GTK 3.12 de mémoire, GtkHeaderBar est utilisé même par les applications de base :-|.

Une solution serait de patcher GtkHeaderBar pour avoir un comportement "natif" -en gros détecter qu'elle n'est pas sous GNOME, réafficher une barre native, et éventuellement dessiner ses widgets custom dans un espace en-dessous.. Mais j'ignore si ce serait accepté par GNOME.

Je viens d'essayer de le faire tourner sous Wayland, ça ne fonctionne pas (probablement parce qu'il y a bien plus que GTK+ dans le moteur de rendu Firefox, qui ne l'utilise peut-être que pour les widgets) :

export GDK_BACKEND=wayland
firefox-gtk3

Ici ça bloque sur la recherche d'un "display: :0".
Il est bien sûr possible que je me trompe ; dans ce cas faites signe !

Si j'étais lui, j'aurais juste envie de te dire d'aller te faire voir ailleurs et que si tu crache sur des débuts de solutions sans chercher à discuter t'as qu'à aller voir ailleurs puisque l'herbe y est si verte

Oh ça va, je prends pas ça tellement à coeur… Zenitram ;-).

Sinon, blague à part, je viens de finir de porter le code de GCR et Evolution vers win32. Ca veut dire qu'à l'exception du bureau lui-même, la quasi-totalité du framework est maintenant compilable pour cet OS.

Je repasse sur le toolkit, et en profite pour réitérer mon appel à contributions du côté Win32 et OSX.

Rien à faire des modules, dans Qt c'est une très simple commande et point barre.

OK, d'accord.

Tu pourrais au moins concéder une certaine honte a écrire ce qu'on t'as dit tellement c'est énorme comme réponse. Tu carricatures le journal sur la partie "l'attitude détestable des devs Gtk/GNOME".

Honte ? Et puis quoi encore ? Non mais faut pas exagérer, on parle d'un choix de design qui ne fait pas l'unanimité, pas d'un crime de lèse-UI :D.
Tu dramatises beaucoup tout ça… Moi ça ne me choque pas, parce que je n'en ai pas besoin (sinon je n'utiliserais pas GTK+) ; tu me poses une question, je vais te chercher la réponse, elle ne te convient pas, qu'est-ce-j'y peux ? Je ne suis pas d'accord avec tout ce que fait l'équipe non plus.

Le point principal est que si cela n'existe pas, il faut le créer. Qt (Digia) a un support dédié pour cela, GTK+ peut le faire d'un façon quelconque mais il n'y a pas de secret.

OK, donc voilà ce que ça donne :

GtkFileChooser a la même apparence partout pour avoir une unité parfaite d'esthétique et de fonctionnalités sur toutes les plate-formes.
Implémenter des boîtes de dialogue natives serait possible, pas dans GTK+ directement mais via un module qui pourrait être optionnellement installé (tout comme GTKGLArea, qui implémente une vue OpenGL avec un code différent pour chaque OS). C'est juste que personne ne l'a encore codé.

A titre perso, je pourrais éventuellement le faire, juste que mon planning est ultra-chargé en ce moment. Comme d'hab…

GTK+, c'est un message "Firefox can't establish a connection to the server at www.tarnyko.net."? ;-)

Corrigé ;-).

le truc le plus énorme dans une appli GTK+, c'est la boite d'ouverture de fichiers imonde ailleurs que sous GNOME

Bien que ça ne m'ait jamais dérangé, la critique revient souvent. Techniquement, il est tout à fait possible d'appeler une boîte de dialogue native ; je ne pense même pas que ce soit compliqué (il y aura juste certaines fonctions indisponibles). Je vais poser la question pour savoir pourquoi on ne le fait pas.

Juste un mot sur "le support pourri des autres plate-formes que Linux".

Comme le rappelle Pierre Maziere (1er commentaire), GTK+ est surtout poussé par une communauté ; et c'est spécialement vrai pour les ports Win32 et OSX, qui n'intéressent pas forcément les sponsors officiels de GTK+/GNOME. Logique.

Or, beaucoup de gens sont intéressés (lire : se plaignent) de ces ports, mais assez peu contribuent. Moi-même, qui contribue pour Win32, ai déjà proposé de "coacher" un contributeur OS X sans succès. Il faut bien réaliser ça, et essayer de réagir constructivement.

En passant, les captures de Dirk sont un peu orientées : un logiciel GTK+ sous Win32 aujourd'hui, ça ressemble plutôt à ça. A sa décharge, il utilise encore GTK+2, qui est passé en mode "maintenance" et est moins avancé que GTK+3 de ce côté. Il aurait pu nettement améliorer la situation, mais a préféré migrer suite aux obstacles qu'il cite.

A titre personnel, je trouve que GTK+ est assez bien construit considérant son langage de référence et son extensibilité.
Le retour des développeurs, la documentation… c'est autre chose.

Si, les EFL fonctionnent sous win32, il existe d'ailleurs un process de build officiel (les fonctions sont wrappées via la sous-bibliothèque "Evil").

Pour OSX, aucune idée.

Je t'en prie !

Bon en tous cas, je réessaye pour master, et je te tiens au courant.

OK. Fais juste attention, depuis peu, mingw32 n'est plus utilisable -et mon buildenv non plus, donc (mingw64 requis).

Salut Jehan,

Désolé pour la réponse tardive, mais je n'ai pas vu ton commentaire jusqu'à maintenant (peut-être peut-on se faire prévenir par mail ?).

j'ai voulu cross-compiler gtk+ master à l'instant, et ça foire

master subit fréquemment des modifs de développeurs purs Unix/Linux qui n'envisagent pas le cas "Windows". Je passe donc derrière pour réparer (par exemple ça). Tu peux réessayer maintenant, il est tout à fait probable que ça fonctionne.

Quand je regarde les Makefile.am, je constate que c'est normal

Non, j'ai rarement dû toucher aux Makefile.am, les versions du moment sont propres.

tu compiles avec les autotools ou avec un autre système de build

autotools/mingw, avec des scripts perso. Tu peux trouver des anciennes versions du buildenv ici. J'ai malheureusement pas encore eu le temps d'y mettre celui de la "prod".

tu compiles sous Windows, ou tu cross-compiles?

Je cross-compile. Idéalement je ferais sous win, c'est 1000x plus facile et aussi performant, mais les binaires fournis doivent provenir d'une machine GNOME pour être certifiés = Linux.

je vois des makefile.msc

Les scripts MSVC sont fournis par d'autres contributeurs. Je ne les utilise pas, à la fois pour éviter les problèmatiques de version de CRT, et parce que je maîtrise moins bien ce compilateur.

Très intéressant, merci !

À noter pour les afficionados d'OpenGL 1.X/2.X qu'il n'est pas explicitement dit que cela supporté (même si on parle à un moment de "compatibility profiles"). Je suppose que ça dépendra de la lib du vendeur.

Clutter ne peut pas vraiment être considéré comme GTK+ (malgré la présence du binding clutter-gtk).

J'en distribue cependant des binaires (non-officiels) ; c'est concu pour être aspiré par ValaWinPKG, mais on peut aussi télécharger l'archive directement.
Ca marche plutôt bien.

Dans le temps, il y avait un moteur (engine) GDK nommé GTK-Wimp qui servait de "glue" entre GTK+ et les widgets natifs de Windows.

Il n'a pas été porté sous GTK+3, mais je suppose que c'est loin d'être infaisable.
Une solution plus rapide serait d'écrire un simple accesseur capable de "lire" les icônes dans les binaires systèmes (comme shell32.dll) pour les réafficher via Gdk-Pixbuf ou Cairo.

Plein d'idées, plein de projets !