Sauf que les choses en question sont normalement gérées par le toolkit.
Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events. Sauf que là on aura plus de message X11, donc deux solutions :
- a) On créé un "serveur" dont le but est de passer générer les évènements attendus par l'appli. En d'autres termes on fait un mini serveur de messages dans chaque appli. C'est ce qui est conforme à l'architecture Wayland après tout. Mais la ce pose un problème avec les plugins. Supposons que mon appli principale ai besoin demande à accéder seulement à certains évènements - je ne vais pas compiler mon appli pour capter tous les messages possibles et imaginables - Sauf que si j'ai un plugin qui a besoin d'évènements en plus que l'appli principale, je fais quoi ? Je compile un second serveur pour chopper les évènements "en plus", au risque d'avoir des incohérences (par exemple des raccourcis clavier qui ne marchent plus si le plugin a le focus) ?
- b) On rajoute quelques lignes de codes, notamment dans les callback des plugins pour éviter à gimp de se fader 27 serveurs de messages au bout de deux heures d'utilisation ? On modifie légèrement la portée de certaines RPC pour qu'elle puisse surcharger le serveur d'évènements ?
Il y a aussi une branche pour les "client-side decorations"
Plusieurs même, une qui est utilisée principalement par Compiz, et une autre par Gnome 3. Or toutes les applications GTK ne sont pas des applis soit Compiz soit gnome 3. Et comme des décorations de fenêtre coté client existe, on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent (en fait il faudrait que le compilo s’assure du besoin ou non de rajouter des décoration fenêtre par fenêtre - c'est pas impossible, mais ça peut être complexe). En plus les solutions de décorations client s'appuient massivement sur GConf (donc Gnome) pour chopper les éléments graphiques dont elles ont besoins (on pourrait inclure les éléments en dur dans l'application, mais bonjour les changements de thème). Donc sur ce point là je ne vois pas comment on peut se passer de réécrire, au moins en partie le code.
Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres. Le code pour se rattacher à ce serveur serait inclus de base dans les libs et limiterait pas mal le code à réécrire pour fonctionner complètement sous Wayland. Mais là aussi ça demande un gros effort et ca ferait double emploi avec pas mal de fonctionnalités de Gnome. Wait and see donc, mais je parie sur de la réécriture de code dans toutes les applis ou presque.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Sauf que les choses en question sont normalement gérées par le toolkit.
Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events. Sauf que là on aura plus de message X11, donc deux solutions :
- a) On créé un "serveur" dont le but est de passer générer les évènements attendus par l'appli. En d'autres termes on fait un mini serveur de messages dans chaque appli. C'est ce qui est conforme à l'architecture Wayland après tout. Mais la ce pose un problème avec les plugins. Supposons que mon appli principale ai besoin demande à accéder seulement à certains évènements - je ne vais pas compiler mon appli pour capter tous les messages possibles et imaginables - Sauf que si j'ai un plugin qui a besoin d'évènements en plus que l'appli principale, je fais quoi ? Je compile un second serveur pour chopper les évènements "en plus", au risque d'avoir des incohérences (par exemple des raccourcis clavier qui ne marchent plus si le plugin a le focus) ?
- b) On rajoute quelques lignes de codes, notamment dans les callback des plugins pour éviter à gimp de se fader 27 serveurs de messages au bout de deux heures d'utilisation ? On modifie légèrement la portée de certaines RPC pour qu'elle puisse surcharger le serveur d'évènements ?
Il y a aussi une branche pour les "client-side decorations"
Plusieurs même, une qui est utilisée principalement par Compiz, et une autre par Gnome 3. Or toutes les applications GTK ne sont pas des applis soit Compiz soit gnome 3. Et comme des décorations de fenêtre coté client existe, on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent (en fait il faudrait que le compilo s’assure du besoin ou non de rajouter des décoration fenêtre par fenêtre - c'est pas impossible, mais ça peut être complexe). En plus les solutions de décorations client s'appuient massivement sur GConf (donc Gnome) pour chopper les éléments graphiques dont elles ont besoins (on pourrait inclure les éléments en dur dans l'application, mais bonjour les changements de thème). Donc sur ce point là je ne vois pas comment on peut se passer de réécrire, au moins en partie le code.
Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres. Le code pour se rattacher à ce serveur serait inclus de base dans les libs et limiterait pas mal le code à réécrire pour fonctionner complètement sous Wayland. Mais là aussi ça demande un gros effort et ca ferait double emploi avec pas mal de fonctionnalités de Gnome. Wait and see donc, mais je parie sur de la réécriture de code dans toutes les applis ou presque.