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.
Ç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.
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.
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.
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.
À 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.
on a toujours le droit au même immonde thème d'icônes
Les thèmes d'icônes sont personnalisables sous win32 aussi, il y a un "settings.ini" comme sous Linux, et même les formats vectoriels (SVG) sont gérés…
Après, inclure plein de thèmes, ça fait vite un bundle de 200 Mo. Alors que la demande était au contraire "plus petit possible" !
Maintenant il suffirait d'une bonne âme pour nous écrire une petite appli GTK+3-Windows récupèrant les thèmes sur les dépôts du Net, et les activant/désactivant dans ce fameux fichier ;-).
pourquoi avoir attendu autant de temps avant de mettre à disposition des binaires officiels de GTK+3
Question de support. Il faut qu'une ou plusieurs personnes se dévouent pour servir de "point d'entrée" aux questions, faire des revues de patches, discuter avec les développeurs…
la présence de ces binaires officiels changent quelques chose ?
Meilleurs rapports de bugs (puisque les gens seront incités à utiliser tous les mêmes binaires, pas une version compilée dans un coin avec des options et patches inconnus), reconnaissance de la qualité du port, garantie de confiance pour les développeurs tiers…
L'archive de Tuma ? Oui, elle marche pas trop mal ; je ne l'ai pas mentionnée car elle utilise des versions très anciennes, et craignais qu'on me le reproche.
Il faudrait en refaire une version à jour à partir des sources, avec des patchs documentés.
Effectivement ; d'autant qu'il intègre GLU (ce que jwzgl ne fait pas) et peut remplacer libGL.so à l'exécution, sans besoin de recompiler.
Il a par contre comme jwzgl parfois tendance à se tromper dans les profondeurs.
PS : L'idéal serait quand même d'avoir une vraie implémentation de référence. J'ai trouvé ça en rapport au commentaire de Léo, mais ça ne fournit pas EGL et ne me paraît pas encore prêt d'arriver, si ?
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Nécessitait.
[^] # Re: Oups!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Doit remarcher maintenant.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 4.
La réalité.
:-D :-(
[^] # Re: Cairo ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlmessage, un équivalent à xmessage. Évalué à 2.
Hello nazcafan,
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+.
Page blanche, j'avoue (rougit). J'ignore si j'aurais pu réutiliser un peu ou beaucoup.
[^] # Re: Ne pas dépendre d'un toolkit == créer un autre toolkit linké statiquement
Posté par Tarnyko (site web personnel) . En réponse au journal wlmessage, un équivalent à xmessage. Évalué à 7. Dernière modification le 30 mai 2014 à 13:47.
Salut, et merci pour tes encouragements,
Il n'y en aura pas, je pense. wlmessage gardera la même apparence partout.
Ç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.
[^] # Re: GNOME et le gestionnaire de fenêtre
Posté par Tarnyko (site web personnel) . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 5. Dernière modification le 30 mai 2014 à 13:01.
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…
[^] # Re: GNOME et le gestionnaire de fenêtre
Posté par Tarnyko (site web personnel) . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 4.
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.
# Pas pur Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Firefox en GTK3. Évalué à 3.
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) :
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 !
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
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.
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
OK, d'accord.
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.
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
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…
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
Corrigé ;-).
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.
# Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
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.
[^] # Re: Hélas toujours pas...
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Enlightenment 0.18 EFL 1.8.3 & Elementary . Évalué à 2.
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.
[^] # Re: Tu compiles depuis Win ou en natif?
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
Je t'en prie !
OK. Fais juste attention, depuis peu, mingw32 n'est plus utilisable -et mon buildenv non plus, donc (mingw64 requis).
[^] # Re: Tu compiles depuis Win ou en natif?
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
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 ?).
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.
Non, j'ai rarement dû toucher aux Makefile.am, les versions du moment sont propres.
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".
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.
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.
[^] # Re: Ne pas confondre !
Posté par Tarnyko (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 1.
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.
[^] # Re: Et Clutter ?
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
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.
[^] # Re: Non mais sérieusement
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 3.
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 !
[^] # Re: Non mais sérieusement
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 6.
Les thèmes d'icônes sont personnalisables sous win32 aussi, il y a un "settings.ini" comme sous Linux, et même les formats vectoriels (SVG) sont gérés…
Après, inclure plein de thèmes, ça fait vite un bundle de 200 Mo. Alors que la demande était au contraire "plus petit possible" !
Maintenant il suffirait d'une bonne âme pour nous écrire une petite appli GTK+3-Windows récupèrant les thèmes sur les dépôts du Net, et les activant/désactivant dans ce fameux fichier ;-).
[^] # Re: Questions de débutant + Erreurs
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
De rieeeeen !
[^] # Re: Questions de débutant + Erreurs
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 9.
Question de support. Il faut qu'une ou plusieurs personnes se dévouent pour servir de "point d'entrée" aux questions, faire des revues de patches, discuter avec les développeurs…
Meilleurs rapports de bugs (puisque les gens seront incités à utiliser tous les mêmes binaires, pas une version compilée dans un coin avec des options et patches inconnus), reconnaissance de la qualité du port, garantie de confiance pour les développeurs tiers…
[^] # Re: Binding Python !!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
L'archive de Tuma ? Oui, elle marche pas trop mal ; je ne l'ai pas mentionnée car elle utilise des versions très anciennes, et craignais qu'on me le reproche.
Il faudrait en refaire une version à jour à partir des sources, avec des patchs documentés.
[^] # Re: Enfin !!!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
Oui, le GTK+ de MacPorts et HomeBrew utilise X11, à moins de spécifier le contraire ; par exemple avec MacPorts :
port install gtk3 +quartz -x11 +nox11_
Je fournis un bundle OSX (non-officiel) avec Quartz pour ceux qui veulent tester, mais l'installeur OSX-Vala avec création automatique des raccourcis et variables d'env. est sans doute le plus rapide.
[^] # Re: glshim
Posté par Tarnyko (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 1.
Effectivement ; d'autant qu'il intègre GLU (ce que jwzgl ne fait pas) et peut remplacer libGL.so à l'exécution, sans besoin de recompiler.
Il a par contre comme jwzgl parfois tendance à se tromper dans les profondeurs.
PS : L'idéal serait quand même d'avoir une vraie implémentation de référence. J'ai trouvé ça en rapport au commentaire de Léo, mais ça ne fournit pas EGL et ne me paraît pas encore prêt d'arriver, si ?