Tant mieux, ce n'est pas à l'application de gérer sa fenêtre, c'est le rôle du… gestionnaire de fenêtre :-)
Exactement, j'ai jamais compris pourquoi Gtk/Gdk ont autorisé le placement des fenêtre dans l'API. À mon avis les développeurs de kicad n'ont jamais utilisé un gestionnaire de fenêtre de type tiling. À aucun moment une application n'a besoin de savoir où sa fenêtre doit être et encore moins faire du MDI.
La seule chose qu'une application puisse exiger c'est une taille minimale (éventuellement maximale) et au pire une taille fixe pour les jeux vidéos (et encore, l'idéal serait d'avoir un décor adaptatif pour des résolutions différentes).
L'application peut très bien demander à ce qu'une de ses fenêtres soit traitée d'une façon particulière. Ensuite le mot final revient au gestionnaire de fenêtres, oui.
C'est déjà le cas pour les popups, et pour toutes les actions de fenêtrage lorsqu'on utilise un "Client Side Decoration" (coucou les apps GTK !). Par exemple il y a une extension spécifique KDE pour ça, et probablement un équivalent chez les autres compositeurs.
L'application peut très bien demander à ce qu'une de ses fenêtres soit traitée d'une façon particulière. Ensuite le mot final revient au gestionnaire de fenêtres, oui.
Je pense que ça reste tout de même une mauvaise idée. Cela veut dire que tu as envie de designer un comportement selon une idée très personnelle. Par exemple, disons que tu souhaites que ton popup s'affiche exactement au centre de ton application, pourquoi pas. En revanche, on peut imaginer un compositeur ayant une contrainte très précise comme un écran vertical de téléphone/taablette et cette popup aura probablement pas du tout le même aspect et devra même peut-être occuper tout l'écran pour s'afficher.
Oui, ça tombe bien, c'est à peu près comme ça que ça marche aujourd'hui avec les popups (menu contextuel par exemple). Sur desktop, ça s'affiche sur le lieu du clic, comme demandé par l'appli. Et sur mobile, le compositeur va l'afficher au centre de l'écran, ignorant la demande de l'appli.
C'est marrant cette tendance à jeter radicalement le besoin pour une app de placer ses fenêtres. Il existe des apps multi-fenêtres. C'est ainsi, elles existent. Elles font leur job depuis des années, et si elles ne peuvent plus indiquer ou au moins suggérer un positionnement, par exemple pour présenter convenablement au premier lancement, ou bien pour restaurer la disposition choisie par l'utilisateur au lancement suivant, ou bien pour proposer à l'utilisateur de switcher entre plusieurs positions, et bien elles deviennent soudainement pénibles à utiliser.
L'argument de Dave n'en est pas un, c'est juste une affirmation infondée, un dogme qui n'engage que lui. Et David, tu nous parles d'un truc complètement hypothétique, qu'« on peut imaginer », à opposer à la réalité concrète d'applications belles et bien existantes.
Si une app veut faire n'importe quoi avec ses fenêtres, c'est surtout son problème. Et si ce n'importe quoi convient à l'utilisateur, grand bien lui fasse. Je ne vois pas en quoi le gestionnaire de fenêtres devrait se sentir concerné plus que ça, surtout s'il a la possibilité d'ignorer la demande de l'app ou d'y appliquer plus de contraintes.
Justement il n'en existe pas tant que ça (et celles que je connais sont mal foutus), je trouve que ça se justifie complètement de ne pas gérer ce cas pour rester un serveur d'affichage simple.
Wayland a bien décidé de ne pas gérer le rendu à distance et même de ne pas gérer le rendu du tout :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Si une app veut faire n'importe quoi avec ses fenêtres, c'est surtout son problème
Non, précisément parce que ça implique d'implémenter la fonctionnalité sur chaque plateforme et ça c'est un casse tête sans nom. D'ailleurs, rien que SDL 1.2 ne supportait pas plusieurs fenêtres. Sans parler de tout l'aspect positionnement, gestion du focus et des entrées ou mêmes techniques : combien de personnes se sont déja faites avoir parce que dans la plupart des toolkits UI il est interdit d'utiliser d'utiliser des fonctions UI dans un autre thread que celui de l'UI donc chaque bibliothèque qui créé des threads à notre insu risque de poser problèmes. Alors rendons les choses simples pour l'utilisateur comme pour le développeur.
Pour le multi fenêtrage, il faut pas oublier qu'il n'y a pas que les ordinateurs. Gimp, une application de dessin aurait eu sa place sur un iPad ou tablette mais je n'ose pas imaginer le bordel si la version actuelle n'avait pas fusionné en une fenêtre unique depuis. Sans parler de tous les WMs qui ont du rajouter une règle spécifique à gimp pour ne pas mettre en tuile les fenêtres d'outils.
Je pense qu'une application multi fenêtre a un problème fondamental d'expérience utilisateur même sur un écran tout à fait normal sans limite de positionnement. Si je ferme une fenêtre accidentellement, je dois me prendre la tête à retrouver où on l'ouvre dans l'application.
Sur le principe, je suis d’accord, mais en pratique il y a un certain nombre d’applications qui fonctionnent sensiblement moins bien sans cette fonctionnalité et qui ne seront vraisemblablement jamais modifiées uniquement pour faire plaisir à Wayland.
Une liste d’applications nécessitant ce protocole ici.
Lazarus IDE : l'IHM est multi fenêtre est déjà très pénible avec X11. Elle reprends l'IHM de Delphi qui était aussi très pénible sous Windows. Malgré ma grande nostalgie du Pascal Objet, je ne vois pas l'intérêt de continuer de faire de l'acharnement thérapeutique.
Gimp : la pire UX/UI du monde libre, je ne le trouve utilisable qu'en mono fenêtre.
Si les programmes veulent vraiment proposer des IHM avec plusieurs fenêtres, elles peuvent le faire en MDI.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Comme je l’ai dit, je suis d’accord sur le principe, mais ce n’est pas avec 3% des utilisateurs de bureau que tu pèses assez pour imposer ce genre de chose.
À 3%, il vaut mieux être pragmatique qu’idéaliste.
je n'ai rien compris à la discussion concernant Wayland, X11, les gestionnaires de … et de qui fait quoi.
Par contre, c'est marrant, j'ai exactement la sensation inverse :
C'est sans doute parce que je suis plus habitué au dessin technique qu'à tout le reste, mais je retrouve mieux mes petits(esprits) avec KiCad qu'avec Gimp.
"Si tous les cons volaient, il ferait nuit" F. Dard
Je trouve que le titre du commentaire est assez inutilement offensant pour les devs de KiCad.
Pour le débat technique, je ne suis pas compétent pour juger de ce que KiCad, reposant il me semble sur le toolkit wxWidgets, devrait ou pas adopter comme comportement pour que ça fonctionne parfaitement sous Wayland.
Pour le reste je sais que c'est un sport traditionnel de chambrer les équipes de développement de divers projets libres, mais je ne pense pas que "codé avec le cul" soit la bonne manière de décrire KiCad, qui, s'il n'est pas exempt de tout défaut, rend tout de même quelques services à nombre d'électronicien·ne·s, de tout niveau, et ce sur différents OS.
D'ailleurs il n'est pas exclu d'y contribuer, pour le code, la doc, le financement, ce qui ne pourra qu'améliorer le support de Wayland dans un avenir plus proche.
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 ]
D'ailleurs, je remarque qu'ils ont implémenté "xx_session_management_v1", et non "xdg_session_v1", car ce dernier n'est même pas encore fusionné dans Wayland, malgré 5 ans (!) de discussions autour de ce petit morceau de protocole.
Personne ne veut coder un truc compatible x11 pour wayland ? Cela éviterait d avoir des codes path différents, le temps d'avoir des protocoles supportés.
Après ils sont libres de ne pas supporter wayland si ça ne les intéresse pas.
Wayland représente au plus 3% des utilisateurs de bureau. Si une «grosse» application décide d’abandonner Wayland, ce n’est pas l’application qui en souffrira le plus.
Faut voir! Ce serait peut-être même une stat intéressante:
Est-ce qu'on voit une différence d'engagement (dons, contributions) par les utilisateurs suivant les plateformes qu'ils utilisent?
Parce que si les 3% d'utilisateurs (je doute de ce chiffre, en passant, vu que Kicad s'adresse à une population versée dans la techno) représentent 10% des dons (chiffre sorti de [tuuut]), ça peut faire mal si ça ne marche plus.
C'est pas qu'on n'aime pas Wayland. Et d'ailleurs le fait "d'aimer" n'a véritablement aucune importance ni aucun intérêt dans un tel sujet. C'est pas comme si notre appréciation (technique, philosophique, ou autre) d'une technologie peut rentrer en jeu et va changer quoi que ce soit ici. En fait, il est évident que Wayland est le futur du desktop sous Linux, non pas par une évidente supériorité technique (peut-être que ça l'est, mais ce n'est pas la raison dans tous les cas), mais simplement car c'est là où les divers acteurs principaux du bureau Linux se dirigent. Essayer de le nier ou de freiner des deux pieds n'y changera rien. Donc on fait tout notre possible pour prendre en charge ce système d'affichage au mieux, même si c'est pas facile.
Ensuite oui, il manque (ou a manqué pendant longtemps; ça progresse lentement) des fonctionnalités, dont certaines vraiment rédhibitoires, et cela touche divers sujets (colorimétrie, gestion des fenêtres, accessibilité, bonne gestion de base des périphériques d'entrée…) et malheureusement cela rendait Wayland inapte à divers usages pros. Notamment quasiment tous les logiciels de graphisme (dont GIMP, mais pas seulement) à l'heure actuelle ne peuvent pas recommander Wayland. Et l'industrie du graphisme n'est pas une petite industrie!
Pour notre travail, puisqu'on utilise GIMP en production, on doit continuer à utiliser X11 encore aujourd'hui (même si cela pose de plus en plus de problèmes car X11 devient seconde zone et on a des cas de changements qui créent de nouveaux bugs et cassent donc des choses qui marchaient sous X avant mais plus maintenant mais peu s'en préoccupent car X11 n'est plus à l'honneur). On se retrouve donc entre 2 implémentations cassées différemment. C'est vraiment pas une situation très glop. 😕
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour notre travail, puisqu'on utilise GIMP en production, on doit continuer à utiliser X11
Tout dépend de ce que l'on entend par "production". Je n'utilise que Wayland et cela ne m'empêche pas de créer en me servant de Gimp, loin de là. Le problème avec Wayland viendrait plutôt des applis QT/KDE.
Tout dépend de ce que l'on entend par "production".
Tout à fait.
Bon déjà y a les problèmes de colorimétrie, bien que ceci n'est pas forcément un gros problème dans beaucoup de cas.
Ensuite on a eu vraiment une très grosse variété de problèmes avec les tablettes à travers les années et les versions (des bugs disparaissaient mais d'autres apparaissaient). Au point que (surtout au début), on se demandait si on était les seuls au monde à utiliser GNOME sous Wayland pour du dessin dans un contexte professionnel. 🤔
Bon sur ce point, ceci dit, dans l'intervalle entre le moment où les dévs de GNOME ont commencé à se focaliser sur Wayland et à abandonner X11 et maintenant, on a malheureusement vécu plein de nouveaux bugs de tablettes spécifiques à X11 aussi et certains en particulier furent très ennuyeux (par exemple le pointeur qui disparaît parfois et le seul moyen de le récupérer était de débrancher/rebrancher la tablette… bon celui-là a été corrigé à un moment, mais je pense que ce furent au moins 6 mois ou plus assez chiants). Donc bon… y a des bugs chiants avec les 2 systèmes d'affichage, juste différents (bon ceci dit, aux tous débuts alors que GNOME commençait déjà à mettre Wayland par défaut, pendant quelques années, il y avait des bugs qui rendaient l'usage tablette absolument impossible sur Wayland — par exemple, si je me souviens bien, au début on avait un bug où ça dessinait alors que le stylet ne touchait même pas la tablette, ce qui rendait l'usage du système absolument impossible pour nous, sans même le moindre contournement possible; à leur décharge, je crois que le problème arrivait avec les nouveaux stylets des Intuos Pro et pas les modèles moins chers — mais heureusement ces bugs rédhibitoires ne sont plus d'actualité).
Je crois qu'on avait quelques problèmes de multi-écran à un moment donné, mais ces derniers se sont améliorés, je crois.
Enfin il y a les problèmes de stabilité. Malheureusement GNOME plante encore sous Wayland, rarement mais tout de même, pour mois quelques fois par mois (je dirais, à la louche; car c'est pas comme si je gardais un compte). Or lorsque GNOME/X11 plantait, y avait juste globalement un vacillement de l'écran, le temps qu'il relance son système et recrée des fenêtres pour les logiciels qui tournent. C'était peu bloquant. Alors que GNOME/Wayland plante sans savoir se relancer (une régression connue depuis longtemps), on doit relancer la session ainsi que tous les logiciels. Pire: si on n'a pas sauvegardé juste avant, on perd des données. C'est d'autant plus embêtant pour nous, parce que même si Aryeom est la première à dire à ses élèves (quand elle enseignait à l'université) de sauvegarder tout le temps, dans les faits, avec ses véritables fichiers de production qui ont des centaines de calques, ben sauvegarder le fichier peut prendre 10 à 20 secondes. C'est donc assez contraignant (attendre autant en plein milieu du travail coupe l'élan) et elle s'est mise à ne plus sauvegarder toutes les minutes avec ses gros fichiers, surtout que GIMP lui-même est très stable. Alors quand y a un plantage (soit de GIMP quand même, ou créé par un autre logiciel, ça arrive je crois avec Blender qui tourne souvent en même temps, et qui va parfois prendre toutes les ressources et faire des problèmes pour tout le système), c'est chiant et on peut perdre pas mal de travail. Si en plus on rajoute à cela des plantages possibles de GNOME… Donc on évite.
Notons que moi-même, j'utilise de plus en plus GNOME/Wayland, notamment pour justement rapporter les problèmes, vérifier l'évolution, etc. et je peux effectivement constater que c'est de mieux en mieux et surtout de plus en plus stable. Enfin… il m'arrive encore de tomber sur des problèmes. Le dernier en date: il y a quelques semaines, j'ai utilisé Scribus pour aider à préparer des autocollants (qu'on peut voir là) avant envoi à l'imprimeur. À ce moment, j'étais sur GNOME/Wayland depuis quelques mois et ça allait plutôt bien. Sauf que Scribus, pour une raison ou une autre, faisait planter GNOME/Wayland (pas au lancement, mais en faisant divers trucs, à un moment, le bureau entier plantait). Alors je suis passé sur GNOME/X11 et j'ai pu reprendre sans plus aucun plantage.
Pour l'artiste par contre, je la laisse sur GNOME/X11 uniquement car elle a déjà assez à faire pour ne pas avoir à contourner ou subir en plus des bugs critiques et des plantages du bureau entier.
Enfin bon, en conclusion: c'est pas parfait, mais les choses avancent. Ça c'est clair. La différence entre y a quelques années et maintenant est flagrante.
Et je suis tout à fait d'accord que selon ce qu'on fait, avec quel matos, quel est le besoin, la cible du travail, et combien de temps on va passer sur GIMP. Etc. Il est évident que pour certains, ces problèmes sont acceptables (voire inexistants, dans le sens où on ne les rencontre pas dans son cas d'usage). Pour nous, ça ne l'est pas encore tout à fait et par conséquent, on reste encore un peu sur GNOME/X11 (pour la partie "artiste", je veux dire; moi j'utilise Wayland pour la partie dév/technique, gestion, etc.). Pour tout dire, comme ils sont en train de retirer entièrement la prise en charge de X11 dans GNOME, selon comment les choses évoluent dans les années qui viennent, je vais peut-être commencer à retester d'autres environnements de bureau pour rester sur X11 plus longtemps. Hormis si GNOME fait un énorme effort et comble tous les problèmes majeurs de Wayland entretemps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
L'artiste a le mainteneur de GIMP en collègue. Elle a son propre build, avec des fonctionnalités que personne a (parce qu'on les designe et teste nous-même en avant-première et que c'est comme ça qu'on a fait avancer GIMP; et aussi parfois on veut des fonctionnalités en quick'n dirty pour travailler efficacement sur notre projet avant de travailler davantage pour en faire une bonne fonctionnalité générique pour GIMP). 😁
On n'utilise pas Flatpak (même si c'est moi qui l'ai initialement créé pour GIMP).
Quant à changer de bureau (GNOME), on n'en a pas changé depuis le début du projet.
Ensuite faire évoluer GIMP fait partie de la dualité de notre projet, qui est un projet totalement artisanal et expérimental, notamment par nos outils (ce qui a clairement mis beaucoup de bâtons dans les roues de la partie artistique du projet, c'est certain).
Il est évident que dans un contexte plus classique, on aurait été beaucoup plus conservateur dans nos choix techniques. Et si on avait été un projet non libriste et non géré par une asso à but non lucratif qui promeut l'Art Libre et les logiciels libres créatifs (mais disons par une entreprise commerciale à la place), notamment, on aurait fait des choix moins osés et moins militants. Mais voilà… c'est pas notre projet, qui est à la fois artistique, technique, expérimental (dans ces 2 voies), artisanal, évolutif…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il y a un problème de conception à la base : que doit être Wayland?
un remplaçant de x11 avec les mêmes features ?
un nouveau gestionnaire de heu? de quoi tiens ? juste d'affichage ? de sièges (seat) ? de périphériques d'entrées ? seulement clavier/souris ou les manettes ça compte? et pourquoi pas le son (après tout quand on lit une vidéo on aimerait bien avoir le son aussi) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C'est justement les auteurs des logiciels phares qui ont des besoins (Firefox, Gimp, vlc, …). Ce n'est pas forcément à wayland de répondre, mais c'est impensable d'avoir une implémentation différente par environnement (KDE, GTK, …)
un nouveau gestionnaire de heu? de quoi tiens ? juste d'affichage ? de sièges (seat) ? de périphériques d'entrées ? seulement clavier/souris ou les manettes ça compte? et pourquoi pas le son (après tout quand on lit une vidéo on aimerait bien avoir le son aussi) ?
La question c’est comment doit être organisé la stack. L’affichage, le son, l’accélération matèrielle, les input, la gestion d’accès à tout ça… quel acteur (l’appli, le toolkit, le "système" - serveurs d’affichage ou autre) devrait en avoir la charge ou l’accès ?
Mais c’est immensément complexe de faire ce travail dans la non cathédrale qu’est linux.
# Je code avec le cul tralalala
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+9/-3).
Tant mieux, ce n'est pas à l'application de gérer sa fenêtre, c'est le rôle du… gestionnaire de fenêtre :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je code avec le cul tralalala
Posté par David Demelier (site web personnel) . Évalué à 8 (+6/-0).
Exactement, j'ai jamais compris pourquoi Gtk/Gdk ont autorisé le placement des fenêtre dans l'API. À mon avis les développeurs de kicad n'ont jamais utilisé un gestionnaire de fenêtre de type tiling. À aucun moment une application n'a besoin de savoir où sa fenêtre doit être et encore moins faire du MDI.
La seule chose qu'une application puisse exiger c'est une taille minimale (éventuellement maximale) et au pire une taille fixe pour les jeux vidéos (et encore, l'idéal serait d'avoir un décor adaptatif pour des résolutions différentes).
AI is a mental disorder
[^] # Re: Je code avec le cul tralalala
Posté par Christophe . Évalué à 8 (+6/-0).
L'application peut très bien demander à ce qu'une de ses fenêtres soit traitée d'une façon particulière. Ensuite le mot final revient au gestionnaire de fenêtres, oui.
C'est déjà le cas pour les popups, et pour toutes les actions de fenêtrage lorsqu'on utilise un "Client Side Decoration" (coucou les apps GTK !). Par exemple il y a une extension spécifique KDE pour ça, et probablement un équivalent chez les autres compositeurs.
[^] # Re: Je code avec le cul tralalala
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
Je pense que ça reste tout de même une mauvaise idée. Cela veut dire que tu as envie de designer un comportement selon une idée très personnelle. Par exemple, disons que tu souhaites que ton popup s'affiche exactement au centre de ton application, pourquoi pas. En revanche, on peut imaginer un compositeur ayant une contrainte très précise comme un écran vertical de téléphone/taablette et cette popup aura probablement pas du tout le même aspect et devra même peut-être occuper tout l'écran pour s'afficher.
AI is a mental disorder
[^] # Re: Je code avec le cul tralalala
Posté par Christophe . Évalué à 5 (+3/-0).
Oui, ça tombe bien, c'est à peu près comme ça que ça marche aujourd'hui avec les popups (menu contextuel par exemple). Sur desktop, ça s'affiche sur le lieu du clic, comme demandé par l'appli. Et sur mobile, le compositeur va l'afficher au centre de l'écran, ignorant la demande de l'appli.
[^] # Re: Je code avec le cul tralalala
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+11/-1).
C'est marrant cette tendance à jeter radicalement le besoin pour une app de placer ses fenêtres. Il existe des apps multi-fenêtres. C'est ainsi, elles existent. Elles font leur job depuis des années, et si elles ne peuvent plus indiquer ou au moins suggérer un positionnement, par exemple pour présenter convenablement au premier lancement, ou bien pour restaurer la disposition choisie par l'utilisateur au lancement suivant, ou bien pour proposer à l'utilisateur de switcher entre plusieurs positions, et bien elles deviennent soudainement pénibles à utiliser.
L'argument de Dave n'en est pas un, c'est juste une affirmation infondée, un dogme qui n'engage que lui. Et David, tu nous parles d'un truc complètement hypothétique, qu'« on peut imaginer », à opposer à la réalité concrète d'applications belles et bien existantes.
Si une app veut faire n'importe quoi avec ses fenêtres, c'est surtout son problème. Et si ce n'importe quoi convient à l'utilisateur, grand bien lui fasse. Je ne vois pas en quoi le gestionnaire de fenêtres devrait se sentir concerné plus que ça, surtout s'il a la possibilité d'ignorer la demande de l'app ou d'y appliquer plus de contraintes.
[^] # Re: Je code avec le cul tralalala
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 17 juin 2025 à 14:45.
Justement il n'en existe pas tant que ça (et celles que je connais sont mal foutus), je trouve que ça se justifie complètement de ne pas gérer ce cas pour rester un serveur d'affichage simple.
Wayland a bien décidé de ne pas gérer le rendu à distance et même de ne pas gérer le rendu du tout :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je code avec le cul tralalala
Posté par David Demelier (site web personnel) . Évalué à 9 (+7/-0).
Non, précisément parce que ça implique d'implémenter la fonctionnalité sur chaque plateforme et ça c'est un casse tête sans nom. D'ailleurs, rien que SDL 1.2 ne supportait pas plusieurs fenêtres. Sans parler de tout l'aspect positionnement, gestion du focus et des entrées ou mêmes techniques : combien de personnes se sont déja faites avoir parce que dans la plupart des toolkits UI il est interdit d'utiliser d'utiliser des fonctions UI dans un autre thread que celui de l'UI donc chaque bibliothèque qui créé des threads à notre insu risque de poser problèmes. Alors rendons les choses simples pour l'utilisateur comme pour le développeur.
Pour le multi fenêtrage, il faut pas oublier qu'il n'y a pas que les ordinateurs. Gimp, une application de dessin aurait eu sa place sur un iPad ou tablette mais je n'ose pas imaginer le bordel si la version actuelle n'avait pas fusionné en une fenêtre unique depuis. Sans parler de tous les WMs qui ont du rajouter une règle spécifique à gimp pour ne pas mettre en tuile les fenêtres d'outils.
Je pense qu'une application multi fenêtre a un problème fondamental d'expérience utilisateur même sur un écran tout à fait normal sans limite de positionnement. Si je ferme une fenêtre accidentellement, je dois me prendre la tête à retrouver où on l'ouvre dans l'application.
AI is a mental disorder
[^] # Re: Je code avec le cul tralalala
Posté par ChetManley . Évalué à 2 (+1/-0).
Sur le principe, je suis d’accord, mais en pratique il y a un certain nombre d’applications qui fonctionnent sensiblement moins bien sans cette fonctionnalité et qui ne seront vraisemblablement jamais modifiées uniquement pour faire plaisir à Wayland.
Une liste d’applications nécessitant ce protocole ici.
[^] # Re: Je code avec le cul tralalala
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+5/-2).
Dans la liste donnée, je connais juste :
Si les programmes veulent vraiment proposer des IHM avec plusieurs fenêtres, elles peuvent le faire en MDI.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je code avec le cul tralalala
Posté par ChetManley . Évalué à 2 (+1/-0).
Comme je l’ai dit, je suis d’accord sur le principe, mais ce n’est pas avec 3% des utilisateurs de bureau que tu pèses assez pour imposer ce genre de chose.
À 3%, il vaut mieux être pragmatique qu’idéaliste.
[^] # Re: Je code avec le cul tralalala
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Du MDI en multi ecran ?
"La première sécurité est la liberté"
[^] # Re: Je code avec le cul tralalala
Posté par lolop (site web personnel) . Évalué à 2 (+0/-0).
Multiple Document Interface, une fenêtre principale de l'application contient des sous-fenêtres documents.
https://fr.wikipedia.org/wiki/Multiple_document_interface
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Je code avec le cul tralalala
Posté par ChetManley . Évalué à 2 (+1/-0).
Nicolas ne demandait pas ce que MDI veut dire, mais suggérait que le MDI n’est pas très pratique (voire impossible) en multi écrans.
[^] # Re: Je code avec le cul tralalala
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
KiCAD est pire que Gimp 1.1 à l'usage. Le bordel complet (et pourtant j'aime le bordel.). Ça reste un bon logiciel, malgré l'IHM.
[^] # Re: Je code avec le cul tralalala
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
je n'ai rien compris à la discussion concernant Wayland, X11, les gestionnaires de … et de qui fait quoi.
Par contre, c'est marrant, j'ai exactement la sensation inverse :
C'est sans doute parce que je suis plus habitué au dessin technique qu'à tout le reste, mais je retrouve mieux mes petits(esprits) avec KiCad qu'avec Gimp.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Je code avec le cul tralalala
Posté par Maderios . Évalué à 2 (+0/-0).
Le multi fenêtre de Gimp n'étant qu'une option depuis des lustres, ce jugement me semble dépassé.
[^] # Re: Je code avec le cul tralalala
Posté par bistouille . Évalué à 10 (+10/-2).
Bonjour,
Je trouve que le titre du commentaire est assez inutilement offensant pour les devs de KiCad.
Pour le débat technique, je ne suis pas compétent pour juger de ce que KiCad, reposant il me semble sur le toolkit wxWidgets, devrait ou pas adopter comme comportement pour que ça fonctionne parfaitement sous Wayland.
Pour le reste je sais que c'est un sport traditionnel de chambrer les équipes de développement de divers projets libres, mais je ne pense pas que "codé avec le cul" soit la bonne manière de décrire KiCad, qui, s'il n'est pas exempt de tout défaut, rend tout de même quelques services à nombre d'électronicien·ne·s, de tout niveau, et ce sur différents OS.
D'ailleurs il n'est pas exclu d'y contribuer, pour le code, la doc, le financement, ce qui ne pourra qu'améliorer le support de Wayland dans un avenir plus proche.
[^] # Re: Je code avec le cul tralalala
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+22/-0).
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 ]
[^] # Re: Je code avec le cul tralalala
Posté par gorbal . Évalué à 1 (+0/-0).
Il semble que des évolutions arrivent:
https://blogs.kde.org/2025/04/12/this-week-in-plasma-the-beginnings-of-wayland-session-restore/
[^] # Re: Je code avec le cul tralalala
Posté par Christophe . Évalué à 2 (+0/-0).
Oui, lentement… trèès lentement…
D'ailleurs, je remarque qu'ils ont implémenté "xx_session_management_v1", et non "xdg_session_v1", car ce dernier n'est même pas encore fusionné dans Wayland, malgré 5 ans (!) de discussions autour de ce petit morceau de protocole.
[^] # Re: Je code avec le cul tralalala
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 18 juin 2025 à 21:04.
Personne ne veut coder un truc compatible x11 pour wayland ? Cela éviterait d avoir des codes path différents, le temps d'avoir des protocoles supportés.
"La première sécurité est la liberté"
# mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 4 (+4/-3).
Il y a pas mal de mauvaise foi dans leur message.
Après ils sont libres de ne pas supporter wayland si ça ne les intéresse pas.
[^] # Re: mauvaise foi
Posté par ChetManley . Évalué à 6 (+6/-1).
Wayland représente au plus 3% des utilisateurs de bureau. Si une «grosse» application décide d’abandonner Wayland, ce n’est pas l’application qui en souffrira le plus.
[^] # Re: mauvaise foi
Posté par Maclag . Évalué à 5 (+2/-0).
Faut voir! Ce serait peut-être même une stat intéressante:
Est-ce qu'on voit une différence d'engagement (dons, contributions) par les utilisateurs suivant les plateformes qu'ils utilisent?
Parce que si les 3% d'utilisateurs (je doute de ce chiffre, en passant, vu que Kicad s'adresse à une population versée dans la techno) représentent 10% des dons (chiffre sorti de [tuuut]), ça peut faire mal si ça ne marche plus.
[^] # Re: mauvaise foi
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+3/-0).
Il me semble que vlc et gimp n'aime pas non plus wayland car il manque des features de x11.
"La première sécurité est la liberté"
[^] # Re: mauvaise foi
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+15/-0).
C'est pas qu'on n'aime pas Wayland. Et d'ailleurs le fait "d'aimer" n'a véritablement aucune importance ni aucun intérêt dans un tel sujet. C'est pas comme si notre appréciation (technique, philosophique, ou autre) d'une technologie peut rentrer en jeu et va changer quoi que ce soit ici. En fait, il est évident que Wayland est le futur du desktop sous Linux, non pas par une évidente supériorité technique (peut-être que ça l'est, mais ce n'est pas la raison dans tous les cas), mais simplement car c'est là où les divers acteurs principaux du bureau Linux se dirigent. Essayer de le nier ou de freiner des deux pieds n'y changera rien. Donc on fait tout notre possible pour prendre en charge ce système d'affichage au mieux, même si c'est pas facile.
Ensuite oui, il manque (ou a manqué pendant longtemps; ça progresse lentement) des fonctionnalités, dont certaines vraiment rédhibitoires, et cela touche divers sujets (colorimétrie, gestion des fenêtres, accessibilité, bonne gestion de base des périphériques d'entrée…) et malheureusement cela rendait Wayland inapte à divers usages pros. Notamment quasiment tous les logiciels de graphisme (dont GIMP, mais pas seulement) à l'heure actuelle ne peuvent pas recommander Wayland. Et l'industrie du graphisme n'est pas une petite industrie!
Pour notre travail, puisqu'on utilise GIMP en production, on doit continuer à utiliser X11 encore aujourd'hui (même si cela pose de plus en plus de problèmes car X11 devient seconde zone et on a des cas de changements qui créent de nouveaux bugs et cassent donc des choses qui marchaient sous X avant mais plus maintenant mais peu s'en préoccupent car X11 n'est plus à l'honneur). On se retrouve donc entre 2 implémentations cassées différemment. C'est vraiment pas une situation très glop. 😕
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mauvaise foi
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+3/-1).
"Aimer" se voulait un résumé de votre position.
"La première sécurité est la liberté"
[^] # Re: mauvaise foi
Posté par Maderios . Évalué à 2 (+0/-0).
Tout dépend de ce que l'on entend par "production". Je n'utilise que Wayland et cela ne m'empêche pas de créer en me servant de Gimp, loin de là. Le problème avec Wayland viendrait plutôt des applis QT/KDE.
[^] # Re: mauvaise foi
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Tout à fait.
Bon déjà y a les problèmes de colorimétrie, bien que ceci n'est pas forcément un gros problème dans beaucoup de cas.
Ensuite on a eu vraiment une très grosse variété de problèmes avec les tablettes à travers les années et les versions (des bugs disparaissaient mais d'autres apparaissaient). Au point que (surtout au début), on se demandait si on était les seuls au monde à utiliser GNOME sous Wayland pour du dessin dans un contexte professionnel. 🤔
Bon sur ce point, ceci dit, dans l'intervalle entre le moment où les dévs de GNOME ont commencé à se focaliser sur Wayland et à abandonner X11 et maintenant, on a malheureusement vécu plein de nouveaux bugs de tablettes spécifiques à X11 aussi et certains en particulier furent très ennuyeux (par exemple le pointeur qui disparaît parfois et le seul moyen de le récupérer était de débrancher/rebrancher la tablette… bon celui-là a été corrigé à un moment, mais je pense que ce furent au moins 6 mois ou plus assez chiants). Donc bon… y a des bugs chiants avec les 2 systèmes d'affichage, juste différents (bon ceci dit, aux tous débuts alors que GNOME commençait déjà à mettre Wayland par défaut, pendant quelques années, il y avait des bugs qui rendaient l'usage tablette absolument impossible sur Wayland — par exemple, si je me souviens bien, au début on avait un bug où ça dessinait alors que le stylet ne touchait même pas la tablette, ce qui rendait l'usage du système absolument impossible pour nous, sans même le moindre contournement possible; à leur décharge, je crois que le problème arrivait avec les nouveaux stylets des Intuos Pro et pas les modèles moins chers — mais heureusement ces bugs rédhibitoires ne sont plus d'actualité).
Je crois qu'on avait quelques problèmes de multi-écran à un moment donné, mais ces derniers se sont améliorés, je crois.
Enfin il y a les problèmes de stabilité. Malheureusement GNOME plante encore sous Wayland, rarement mais tout de même, pour mois quelques fois par mois (je dirais, à la louche; car c'est pas comme si je gardais un compte). Or lorsque GNOME/X11 plantait, y avait juste globalement un vacillement de l'écran, le temps qu'il relance son système et recrée des fenêtres pour les logiciels qui tournent. C'était peu bloquant. Alors que GNOME/Wayland plante sans savoir se relancer (une régression connue depuis longtemps), on doit relancer la session ainsi que tous les logiciels. Pire: si on n'a pas sauvegardé juste avant, on perd des données. C'est d'autant plus embêtant pour nous, parce que même si Aryeom est la première à dire à ses élèves (quand elle enseignait à l'université) de sauvegarder tout le temps, dans les faits, avec ses véritables fichiers de production qui ont des centaines de calques, ben sauvegarder le fichier peut prendre 10 à 20 secondes. C'est donc assez contraignant (attendre autant en plein milieu du travail coupe l'élan) et elle s'est mise à ne plus sauvegarder toutes les minutes avec ses gros fichiers, surtout que GIMP lui-même est très stable. Alors quand y a un plantage (soit de GIMP quand même, ou créé par un autre logiciel, ça arrive je crois avec Blender qui tourne souvent en même temps, et qui va parfois prendre toutes les ressources et faire des problèmes pour tout le système), c'est chiant et on peut perdre pas mal de travail. Si en plus on rajoute à cela des plantages possibles de GNOME… Donc on évite.
Notons que moi-même, j'utilise de plus en plus GNOME/Wayland, notamment pour justement rapporter les problèmes, vérifier l'évolution, etc. et je peux effectivement constater que c'est de mieux en mieux et surtout de plus en plus stable. Enfin… il m'arrive encore de tomber sur des problèmes. Le dernier en date: il y a quelques semaines, j'ai utilisé Scribus pour aider à préparer des autocollants (qu'on peut voir là) avant envoi à l'imprimeur. À ce moment, j'étais sur GNOME/Wayland depuis quelques mois et ça allait plutôt bien. Sauf que Scribus, pour une raison ou une autre, faisait planter GNOME/Wayland (pas au lancement, mais en faisant divers trucs, à un moment, le bureau entier plantait). Alors je suis passé sur GNOME/X11 et j'ai pu reprendre sans plus aucun plantage.
Pour l'artiste par contre, je la laisse sur GNOME/X11 uniquement car elle a déjà assez à faire pour ne pas avoir à contourner ou subir en plus des bugs critiques et des plantages du bureau entier.
Enfin bon, en conclusion: c'est pas parfait, mais les choses avancent. Ça c'est clair. La différence entre y a quelques années et maintenant est flagrante.
Et je suis tout à fait d'accord que selon ce qu'on fait, avec quel matos, quel est le besoin, la cible du travail, et combien de temps on va passer sur GIMP. Etc. Il est évident que pour certains, ces problèmes sont acceptables (voire inexistants, dans le sens où on ne les rencontre pas dans son cas d'usage). Pour nous, ça ne l'est pas encore tout à fait et par conséquent, on reste encore un peu sur GNOME/X11 (pour la partie "artiste", je veux dire; moi j'utilise Wayland pour la partie dév/technique, gestion, etc.). Pour tout dire, comme ils sont en train de retirer entièrement la prise en charge de X11 dans GNOME, selon comment les choses évoluent dans les années qui viennent, je vais peut-être commencer à retester d'autres environnements de bureau pour rester sur X11 plus longtemps. Hormis si GNOME fait un énorme effort et comble tous les problèmes majeurs de Wayland entretemps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mauvaise foi
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
L'artiste, j'aurais tendance à la mettre sur une distro type LTS qui ne change pas de bureau et de version majeure de kernel tous les 4 matins non?
En plus avec flatpak ça n'empêche pas d'avoir un soft à jour.
[^] # Re: mauvaise foi
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 22 juin 2025 à 01:55.
L'artiste a le mainteneur de GIMP en collègue. Elle a son propre build, avec des fonctionnalités que personne a (parce qu'on les designe et teste nous-même en avant-première et que c'est comme ça qu'on a fait avancer GIMP; et aussi parfois on veut des fonctionnalités en quick'n dirty pour travailler efficacement sur notre projet avant de travailler davantage pour en faire une bonne fonctionnalité générique pour GIMP). 😁
On n'utilise pas Flatpak (même si c'est moi qui l'ai initialement créé pour GIMP).
Quant à changer de bureau (GNOME), on n'en a pas changé depuis le début du projet.
Ensuite faire évoluer GIMP fait partie de la dualité de notre projet, qui est un projet totalement artisanal et expérimental, notamment par nos outils (ce qui a clairement mis beaucoup de bâtons dans les roues de la partie artistique du projet, c'est certain).
Il est évident que dans un contexte plus classique, on aurait été beaucoup plus conservateur dans nos choix techniques. Et si on avait été un projet non libriste et non géré par une asso à but non lucratif qui promeut l'Art Libre et les logiciels libres créatifs (mais disons par une entreprise commerciale à la place), notamment, on aurait fait des choix moins osés et moins militants. Mais voilà… c'est pas notre projet, qui est à la fois artistique, technique, expérimental (dans ces 2 voies), artisanal, évolutif…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 18 juin 2025 à 08:48.
Il y a un problème de conception à la base : que doit être Wayland?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mauvaise foi
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
C'est justement les auteurs des logiciels phares qui ont des besoins (Firefox, Gimp, vlc, …). Ce n'est pas forcément à wayland de répondre, mais c'est impensable d'avoir une implémentation différente par environnement (KDE, GTK, …)
"La première sécurité est la liberté"
[^] # Re: mauvaise foi
Posté par Christophe . Évalué à 3 (+1/-0).
En fait, une partie du problème est là: Wayland est juste un protocole. Les besoins sont divers, les implémentations aussi.
A l'autre bout, une application comme KiCad ne peut que constater la lenteur d'évolution, et la fragmentation des implémentations.
[^] # Re: mauvaise foi
Posté par barmic 🦦 . Évalué à 2 (+1/-1).
La question c’est comment doit être organisé la stack. L’affichage, le son, l’accélération matèrielle, les input, la gestion d’accès à tout ça… quel acteur (l’appli, le toolkit, le "système" - serveurs d’affichage ou autre) devrait en avoir la charge ou l’accès ?
Mais c’est immensément complexe de faire ce travail dans la non cathédrale qu’est linux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mauvaise foi
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+3/-1). Dernière modification le 18 juin 2025 à 13:54.
Alors il faut le faire dans la cathédrale systemd !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mauvaise foi
Posté par Maclag . Évalué à 7 (+5/-1).
Aaaaah! Le 'd' de Wayland, c'est pour çaaaaaa!
(c'est bon, je sais où est la porte, j'ai l'habitude…)
[^] # Re: mauvaise foi
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 19 juin 2025 à 11:50.
Il faut faire une lib allmedia qui essaye de faire ça de façon apparemment unifié ?
Ou alors kyber ou kyber va mettre tout le monde d'accord, d'un coup :)
"La première sécurité est la liberté"
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.