Il faut bien voir que KiCad est aussi un vieux logiciel historique et les attentes n'étaient absolument pas les mêmes y a quelques décennies. Déjà, par définition, les gestionnaires de fenêtres n'étaient pas au même stade d'avancement que maintenant. Donc beaucoup de logiciel implémentaient effectivement des fonctionnalités qui semblent être du ressort du gestionnaire de fenêtre.
Ensuite, même de nos jours, il y a encore pas mal de fonctionnalités liées au placement des fenêtres et à leur restauration que la plupart des gestionnaires de fenêtres gèrent mal, encore à ce jour... voire pas du tout! En fait, on a perdu pas mal de fonctionnalités avec Wayland sur ce point de vue là.
Maintenant cela peut paraître overkill pour les gens qui n'utilisent que des petits logiciels de base. En fait, je pense que pour la plupart des utilisateurs qui n'ont pas de besoins métier, ils n'en verront pas l'intérêt. Ce sont les logiciels dits "métier" (comme GIMP ou KiCad) qui ont des utilisateurs particulièrement avec de tels besoins.
Malheureusement la mode est aux "apps". Les logiciels métiers n'ont plus trop la côtes pour les développeurs de toolkits (des gens de GTK nous ont dit clairement que pour eux, les gros logiciels comme GIMP ne sont plus la cible — ce qui est triste et ironique quand on sait l'histoire de GTK — et que pour eux, le futur est aux innombrables petites "apps" avec 3 boutons et un menu hamburger). Et pour ce genre de logiciel, clairement, ce genre de fonctionnalités est totalement inutile.
Par exemple dans GIMP, le "mode multi-fenêtre" est tout simplement inutilisable sous Wayland, car on perd la sauvegarde de la session. Typiquement un pro voudra placer ses fenêtres multiples à des endroits précis de son ou ses écrans. Et quand il rouvre GIMP, il veut retrouver sa boîte à outil à un endroit précis, son canevas avec une position et taille donnée, les diverses boîtes ancrables aussi à des endroits précis (choix de couleur, navigation, etc.). Ça marche parfaitement sous X11. Mais sous Wayland, vous fermez GIMP, puis le rouvrez et trouverez vos fenêtres à des positions aléatoires car Wayland ne donne aucune position (ni me permet d'ouvrir des fenêtres à des positions données).
Cela est un réel besoin pour les gens qui utilisent des logiciels avec beaucoup de fenêtres et qui ont besoin de les voir se repositionner aux mêmes endroits à chaque fois qu'ils relancent leur logiciel (surtout s'ils le font au quotidien, ce qui sera en général le cas des professionnels pour leurs logiciels de travail).
Il existe d'autres usages qui sont vachement cassés globalement sur la plupart des compositeurs Wayland, comme le fait d'avoir des fenêtres qu'on va détacher et ré-attacher à d'autres fenêtres de manière générale. C'est une fonctionnalité qui pourra être avoir un comportement totalement inattendu. Typiquement un moyen de "casser" totalement votre interface dans GIMP, sous Wayland à l'heure actuelle, est de passer du mode simple-fenêtre au mode multi-fenêtre, puis de revenir en simple fenêtre. Normalement vos fenêtres devraient s'ancrer dans votre fenêtre unique relativement à leur position d'origine (une fenêtre à gauche est ancrée à gauche du canevas, et une fenêtre à droite sera à droite du canevas; et toutes les fenêtres ancrables gardent leur positions respectives les unes par rapport aux autres). Sauf que ça marche pas! Vous retrouverez vos fenêtres ancrées n'importe comment dans la fenêtre unique: https://gitlab.gnome.org/GNOME/gimp/-/issues/12230
Tous ces besoins réels ont des discussions en cours pour avoir des protocoles Wayland, depuis de nombreuses années en fait. Je ne compte même plus le nombre de tentatives de nouveaux protocoles pour essayer de réimplementer ces fonctionnalités d'une manière ou d'une autre, car beaucoup se sont faites recalées. Ensuite parfois j'envoie quelques commentaires, mais je ne participe pas énormément car les discussions autour des protocoles Wayland sont particulièrement éreintantes, avec beaucoup de participants, énormément de commentaires, des gens en désaccord profond sur plein de choses et parfois des commentaires mal à propos. En tous les cas, GIMP ou KiCad sont loin d'être les seuls avec ce genre de fonctionnalités. En fait, je crois que beaucoup des "vieux" logiciels métiers ont ce type de possibilités avancées de gestion de leurs fenêtres.
Ensuite, oui je suis d'accord, si ça peut être implémenté par le gestionnaire de fenêtres, c'est mieux. Mais jusqu'à présent, ce n'est implémenté dans aucun gestionnaire Wayland, ou quand ça l'est, c'est expérimental et différent d'un gestionnaire à l'autre. Donc notre code devrait avoir plusieurs implémentations, ou simplement aucune car justement si on utilise un toolkit, c'est bien parce qu'on aimerait ne pas avoir à s'occuper de ce genre de fonctionnalités (il faut donc attendre que (1) il y ait un protocole unique qui passe "standard" (2) les divers compositeurs Wayland implémentent ce standard (3) les divers toolkits — GTK pour nous par exemple — l'implémentent de leur côté aussi et enfin (4) les logiciels changent leur code pour utiliser spécifiquement ce nouveau protocole.
Cela doit être fait pour chaque fonctionnalité à propos. Alors que dans le vieux modèle où tout ce qui était nécessaire, c'était 2 APIs (une pour récupérer la position d'une fenêtre et une pour faire une requête de positionnement), maintenant il faudra des protocoles spécifiques pour chaque type de besoin, tel que:
Un protocole de gestion des sessions temporaires (utile pour les logiciels qui veulent se mettre en tâche de fond pour ensuite réapparaître exactement comme avant; ou pour la gestion de reprise automatique de session en cas de plantage)
Ce même protocole pourra-t-il être utilisé pour récupérer des sessions de fenêtres entre 2 lancements du programme? Peut-être... ou peut-être faudra-t-il un autre protocole spécifique pour ce cas d'usage différent.
Pour la problématique du détachement/ré-attachement de fenêtre, qui nécessite au moins un concept de positionnement relatif des fenêtres, il y a déjà eu plusieurs tentative de création de protocole, tel que celui assez "direct", puis l'idée de positions relatives et maintenant l'idée de zones de placement.
Pour les fenêtres de lancement (pour les logiciels complexes qui ont pas mal de données à charger, et cela permet de donner un retour visuel sur le chargement et de ne pas donner l'air que le programme ne veut pas se lancer alors qu'il met juste du temps pour cela), il y a aussi un protocole dédié en cours de discussion.
Et peut-être d'autres usages à découvrir...
Notons aussi que même si en théorie, c'est mieux pour ces cas spécifiques si on a un protocole dédié (par exemple, un protocole de session pourrait avoir une simple fonction pour dire store_window_session_data() — où un programme demanderait simplement au compositeur de sauvegarder les infos de session d'une fenêtre — puis apply_window_session_data() où il demanderait plus tard de les réappliquer sur une nouvelle fenêtre; c'est sûr, c'est plus simple que d'avoir à sauvegarder soi-même des positions ainsi qu'un identifiant moniteur, un identifiant pour chaque fenêtre, les mettre dans un fichier côté donnés du logiciel, et ainsi de suite, et en plus obtenir ainsi des données sensibles — puisque l'idée est que Wayland ne veut plus donner d'info aux logiciels sur ce qu'il y a à l'écran), dans la pratique, ça fait qu'il y aura un code spécial pour tous ces usages, juste pour Wayland. En effet la logique du positionnement marche sur tous les autres systèmes et OS (X11, Windows, macOS, BSD, et autres...), donc le code unique actuel marche partout. Ainsi même si dans la théorie, une API dédiée a du sens et devrait même rendre le code plus simple, dans la pratique, ce ne sera pas le cas et devient surtout une implémentation alternative (donc ça complexifie le code).
Aussi à chaque fois qu'un cas d'usage différent est décelé, il faudra probablement un nouveau protocole dédié (impliquant possiblement des années de travail pour sa création, puis d'attente pour qu'il soit implémenté par tous les compositeurs puis toolkits puis logiciels finaux), alors que l'API très simple de positionnement originelle était générique et donc permettait de tout implémenter.
Au final, je suis aussi un peu circonspect. Et la logique qui consiste à dire "c'est le rôle du gestionnaire de fenêtre", bien que partiellement vraie dans l'absolu (parce qu'il reste tout de même nécessaire que l'application implémente quelque chose dans son coin! Quand KiCad ou GIMP parle de "restauration" de fenêtre, donc de session, il faut bien que l'application dise au gestionnaire de fenêtre quelle fenêtre en particulier est à restaurer, à la place de quelle autre fenêtre qui eut existé, parce que le gestionnaire de fenêtre n'a aucune information interne sur les fenêtres, leur rôle et la nécessité de sauver ou non leur emplacement; il a besoin que l'application lui donne ces infos; ce n'est donc malheureusement pas uniquement le rôle du gestionnaire de fenêtre, ce que j'aurais bien aimé car un développeur est toujours content d'avoir moins à gérer! 😅), n'est juste pas en accord avec la réalité du paysage logiciel qui fut construit dans les dernières décennies:
Oui, les logiciels métier ont souvent plusieurs fenêtres, sont souvent affichés sur plusieurs moniteurs et les gens veulent qu'ils sauvegardent les positions entre sessions, surtout quand ce sont des logiciels avec interface hautement personnalisable qu'on modifie aux petits oignons pour son propre usage et travailler plus confortablement.
Oui, les logiciels qui tournent en tâches de fond veulent pouvoir cacher leur(s) fenêtre(s) et les réafficher exactement dans la même position et taille en les rouvrant (on veut pas que notre logiciel s'ouvre différemment à chaque fois qu'on cache puis rouvre des fenêtres).
Oui la sauvegarde de sessions en cas de plantage du système d'affichage est un énorme gain de temps (c'est un des trucs qui a disparu avec le passage à Wayland; maintenant si GNOME plante, on perd tout et on doit redémarrer tous les logiciels, alors que dans sa version X11 par exemple, GNOME Shell était capable de se relancer et recréer immédiatement toutes les fenêtres des logiciels en cours sans les laisser planter).
Oui on veut pouvoir détacher et réattacher automatiquement de multiples fenêtres en prenant en compte les positions relatives entre les fenêtres.
Et ainsi de suite.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je code avec le cul tralalala
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Kicad devs: do not use Wayland. Évalué à 10.
Il faut bien voir que KiCad est aussi un vieux logiciel historique et les attentes n'étaient absolument pas les mêmes y a quelques décennies. Déjà, par définition, les gestionnaires de fenêtres n'étaient pas au même stade d'avancement que maintenant. Donc beaucoup de logiciel implémentaient effectivement des fonctionnalités qui semblent être du ressort du gestionnaire de fenêtre.
Ensuite, même de nos jours, il y a encore pas mal de fonctionnalités liées au placement des fenêtres et à leur restauration que la plupart des gestionnaires de fenêtres gèrent mal, encore à ce jour... voire pas du tout! En fait, on a perdu pas mal de fonctionnalités avec Wayland sur ce point de vue là.
Maintenant cela peut paraître overkill pour les gens qui n'utilisent que des petits logiciels de base. En fait, je pense que pour la plupart des utilisateurs qui n'ont pas de besoins métier, ils n'en verront pas l'intérêt. Ce sont les logiciels dits "métier" (comme GIMP ou KiCad) qui ont des utilisateurs particulièrement avec de tels besoins.
Malheureusement la mode est aux "apps". Les logiciels métiers n'ont plus trop la côtes pour les développeurs de toolkits (des gens de GTK nous ont dit clairement que pour eux, les gros logiciels comme GIMP ne sont plus la cible — ce qui est triste et ironique quand on sait l'histoire de GTK — et que pour eux, le futur est aux innombrables petites "apps" avec 3 boutons et un menu hamburger). Et pour ce genre de logiciel, clairement, ce genre de fonctionnalités est totalement inutile.
Par exemple dans GIMP, le "mode multi-fenêtre" est tout simplement inutilisable sous Wayland, car on perd la sauvegarde de la session. Typiquement un pro voudra placer ses fenêtres multiples à des endroits précis de son ou ses écrans. Et quand il rouvre GIMP, il veut retrouver sa boîte à outil à un endroit précis, son canevas avec une position et taille donnée, les diverses boîtes ancrables aussi à des endroits précis (choix de couleur, navigation, etc.). Ça marche parfaitement sous X11. Mais sous Wayland, vous fermez GIMP, puis le rouvrez et trouverez vos fenêtres à des positions aléatoires car Wayland ne donne aucune position (ni me permet d'ouvrir des fenêtres à des positions données).
Cela est un réel besoin pour les gens qui utilisent des logiciels avec beaucoup de fenêtres et qui ont besoin de les voir se repositionner aux mêmes endroits à chaque fois qu'ils relancent leur logiciel (surtout s'ils le font au quotidien, ce qui sera en général le cas des professionnels pour leurs logiciels de travail).
Il existe d'autres usages qui sont vachement cassés globalement sur la plupart des compositeurs Wayland, comme le fait d'avoir des fenêtres qu'on va détacher et ré-attacher à d'autres fenêtres de manière générale. C'est une fonctionnalité qui pourra être avoir un comportement totalement inattendu. Typiquement un moyen de "casser" totalement votre interface dans GIMP, sous Wayland à l'heure actuelle, est de passer du mode simple-fenêtre au mode multi-fenêtre, puis de revenir en simple fenêtre. Normalement vos fenêtres devraient s'ancrer dans votre fenêtre unique relativement à leur position d'origine (une fenêtre à gauche est ancrée à gauche du canevas, et une fenêtre à droite sera à droite du canevas; et toutes les fenêtres ancrables gardent leur positions respectives les unes par rapport aux autres). Sauf que ça marche pas! Vous retrouverez vos fenêtres ancrées n'importe comment dans la fenêtre unique: https://gitlab.gnome.org/GNOME/gimp/-/issues/12230
Tous ces besoins réels ont des discussions en cours pour avoir des protocoles Wayland, depuis de nombreuses années en fait. Je ne compte même plus le nombre de tentatives de nouveaux protocoles pour essayer de réimplementer ces fonctionnalités d'une manière ou d'une autre, car beaucoup se sont faites recalées. Ensuite parfois j'envoie quelques commentaires, mais je ne participe pas énormément car les discussions autour des protocoles Wayland sont particulièrement éreintantes, avec beaucoup de participants, énormément de commentaires, des gens en désaccord profond sur plein de choses et parfois des commentaires mal à propos. En tous les cas, GIMP ou KiCad sont loin d'être les seuls avec ce genre de fonctionnalités. En fait, je crois que beaucoup des "vieux" logiciels métiers ont ce type de possibilités avancées de gestion de leurs fenêtres.
Ensuite, oui je suis d'accord, si ça peut être implémenté par le gestionnaire de fenêtres, c'est mieux. Mais jusqu'à présent, ce n'est implémenté dans aucun gestionnaire Wayland, ou quand ça l'est, c'est expérimental et différent d'un gestionnaire à l'autre. Donc notre code devrait avoir plusieurs implémentations, ou simplement aucune car justement si on utilise un toolkit, c'est bien parce qu'on aimerait ne pas avoir à s'occuper de ce genre de fonctionnalités (il faut donc attendre que (1) il y ait un protocole unique qui passe "standard" (2) les divers compositeurs Wayland implémentent ce standard (3) les divers toolkits — GTK pour nous par exemple — l'implémentent de leur côté aussi et enfin (4) les logiciels changent leur code pour utiliser spécifiquement ce nouveau protocole.
Cela doit être fait pour chaque fonctionnalité à propos. Alors que dans le vieux modèle où tout ce qui était nécessaire, c'était 2 APIs (une pour récupérer la position d'une fenêtre et une pour faire une requête de positionnement), maintenant il faudra des protocoles spécifiques pour chaque type de besoin, tel que:
Notons aussi que même si en théorie, c'est mieux pour ces cas spécifiques si on a un protocole dédié (par exemple, un protocole de session pourrait avoir une simple fonction pour dire
store_window_session_data()— où un programme demanderait simplement au compositeur de sauvegarder les infos de session d'une fenêtre — puisapply_window_session_data()où il demanderait plus tard de les réappliquer sur une nouvelle fenêtre; c'est sûr, c'est plus simple que d'avoir à sauvegarder soi-même des positions ainsi qu'un identifiant moniteur, un identifiant pour chaque fenêtre, les mettre dans un fichier côté donnés du logiciel, et ainsi de suite, et en plus obtenir ainsi des données sensibles — puisque l'idée est que Wayland ne veut plus donner d'info aux logiciels sur ce qu'il y a à l'écran), dans la pratique, ça fait qu'il y aura un code spécial pour tous ces usages, juste pour Wayland. En effet la logique du positionnement marche sur tous les autres systèmes et OS (X11, Windows, macOS, BSD, et autres...), donc le code unique actuel marche partout. Ainsi même si dans la théorie, une API dédiée a du sens et devrait même rendre le code plus simple, dans la pratique, ce ne sera pas le cas et devient surtout une implémentation alternative (donc ça complexifie le code).Aussi à chaque fois qu'un cas d'usage différent est décelé, il faudra probablement un nouveau protocole dédié (impliquant possiblement des années de travail pour sa création, puis d'attente pour qu'il soit implémenté par tous les compositeurs puis toolkits puis logiciels finaux), alors que l'API très simple de positionnement originelle était générique et donc permettait de tout implémenter.
Au final, je suis aussi un peu circonspect. Et la logique qui consiste à dire "c'est le rôle du gestionnaire de fenêtre", bien que partiellement vraie dans l'absolu (parce qu'il reste tout de même nécessaire que l'application implémente quelque chose dans son coin! Quand KiCad ou GIMP parle de "restauration" de fenêtre, donc de session, il faut bien que l'application dise au gestionnaire de fenêtre quelle fenêtre en particulier est à restaurer, à la place de quelle autre fenêtre qui eut existé, parce que le gestionnaire de fenêtre n'a aucune information interne sur les fenêtres, leur rôle et la nécessité de sauver ou non leur emplacement; il a besoin que l'application lui donne ces infos; ce n'est donc malheureusement pas uniquement le rôle du gestionnaire de fenêtre, ce que j'aurais bien aimé car un développeur est toujours content d'avoir moins à gérer! 😅), n'est juste pas en accord avec la réalité du paysage logiciel qui fut construit dans les dernières décennies:
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]