un programme doit se fader une registry, un "listage" d'interfaces avec des callbacks et des conversions de void* : on dirait du Java en mode ProblemFactory ;
C'est effectivement la base de l'API 😁.
On s'abonne à un "registry" qui va nous indiquer dans un callback les interfaces qu'il suppose ; on s'abonne à celles qui nous intéressent, qui vont nous indiquer dans des callbacks ce qu'il se passe, etc...
Je trouve pas ça si horrible, moi ! L'avantage est que c'est extensible à l'infini, et négociable au runtime. Le fait est que le projet en est très fier, au point de le pousser ailleurs comme protocole IPC généraliste ;-).
PS : les conversions de void*, c'est moi qui les fait à cause du point ci-dessous.
le code doit gérer des variantes selon le "shell" : ça sent l'API parti en prod avant d'être sec
Alors là je suis d'accord, et c'est le plus gros problème à mon sens... juste plus pour longtemps.
Quand Wayland est sorti, l'abstraction du shell (= window manager) s'appelait "wl_shell", elle était tout de suite incomplète pour éviter de prendre trop position (pas de minimisation, pas de passage de focus...) et après coup on s'est aperçus qu'elle avait pas mal de race conditions .
L'alternative nommée "xdg-shell" a passé des années en état instable, il fallait un peu la suivre, et ce n'est que récemment qu'elle est passée stable (sous le nom "xdg-wm-base", pour qu'on la repère bien).
Je les gère encore car je voulais vraiment que les exemples marchent chez tout le monde, même avec du code de 2016. Et du coup ué je convertis les types du shell en void* ;).
Mais on pourrait ne pas le faire et raccourcir tous les exemple de ~50 lignes... ou comme moi ici utiliser "libdecor" qui gère tout ça elle-même !
il n'y a pas d'API pour dessiner, je sais que ce point fait débat, mais ça me semble idiot pour un serveur d'affichage de ne pas savoir afficher :-)
Alors oui c'est clivant. Le fait est que personne n'utilisait plus les API de dessin de X11 (genre "XDrawCircle") car elles étaient vieilles et aliasées, mais passait par celles des libs de toolkits (genre cairo ou Skia).
Wayland a été conçu pour supporter ce cas d'usage, et rien de plus.
[^] # Re: mais mais mais... c'est nul !
Posté par Tarnyko (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 5. Dernière modification le 26 mars 2025 à 15:31.
Haha, tu ne me décois pas, Newt' !
C'est effectivement la base de l'API 😁.
On s'abonne à un "registry" qui va nous indiquer dans un callback les interfaces qu'il suppose ; on s'abonne à celles qui nous intéressent, qui vont nous indiquer dans des callbacks ce qu'il se passe, etc...
Je trouve pas ça si horrible, moi ! L'avantage est que c'est extensible à l'infini, et négociable au runtime. Le fait est que le projet en est très fier, au point de le pousser ailleurs comme protocole IPC généraliste ;-).
PS : les conversions de void*, c'est moi qui les fait à cause du point ci-dessous.
Alors là je suis d'accord, et c'est le plus gros problème à mon sens... juste plus pour longtemps.
Quand Wayland est sorti, l'abstraction du shell (= window manager) s'appelait "wl_shell", elle était tout de suite incomplète pour éviter de prendre trop position (pas de minimisation, pas de passage de focus...) et après coup on s'est aperçus qu'elle avait pas mal de race conditions .
L'alternative nommée "xdg-shell" a passé des années en état instable, il fallait un peu la suivre, et ce n'est que récemment qu'elle est passée stable (sous le nom "xdg-wm-base", pour qu'on la repère bien).
Je les gère encore car je voulais vraiment que les exemples marchent chez tout le monde, même avec du code de 2016. Et du coup ué je convertis les types du shell en void* ;).
Mais on pourrait ne pas le faire et raccourcir tous les exemple de ~50 lignes... ou comme moi ici utiliser "libdecor" qui gère tout ça elle-même !
Alors oui c'est clivant. Le fait est que personne n'utilisait plus les API de dessin de X11 (genre "XDrawCircle") car elles étaient vieilles et aliasées, mais passait par celles des libs de toolkits (genre cairo ou Skia).
Wayland a été conçu pour supporter ce cas d'usage, et rien de plus.