Re: [EGD-discu] Justifications des décisions prises...

[Mélanie Chauvel (ariasuni) <perso@xxxxxxxxxxxxxx>]

Le 03/05/2018 à 22:01, Marcel a écrit :
> Le 03/05/18 14:47 Laurent a écrit :
> […]
>> En effet, mais ça fait trois choses à ajouter pour que ça marche d’origine :
>> – un symbole « virtuel » dans /usr/include/X11/keysymdef.h (j’indique 
>> les chemins classiques sous Linux, mais ça peut différer un peu pour le 
>> début, en particulier sur d’autres systèmes comme FreeBSD),
> Cela me rend perplexe, en fait. Car c’est comme s’il fallait modifier le kbd.h de Windows, 
> à supposer que Windows au lieu des pilotes de disposition, contienne les sources kbdxxxxx.c 
> et en-têtes kbdxxxxx.h de tous les pilotes et les compile lui-même.

En fait tu viens juste de montrer que la façon de gérer les dispositions
de clavier sous Windows a aussi ses défauts. Franchement, Windows est
loin d’être un exemple de ce côté-là.

> Ce serait beaucoup plus lourd à mon avis, et si Linux veut rester léger, cela explique le 
> système d’includes mis en place pour minimiser le tout. Mutualiser le compose sans 
> prévoir de quoi l’override (l’« écraser ») au niveau des dispositions locales facilement, 
> cela aura été à mon avis l’économie d’échelle de trop…

Ça n’est pas une économie d’échelle mais une économie de travail; arrête
de faire des procès d’intention. Personne n’en a eu suffisamment besoin
jusqu’à présent pour que ça soit intégré; ça peut changer.

>> – la règle de composition dans /usr/share/X11/locale/en_US.UTF-8/Compose 
>> (même si son nom ne l’indique pas, ce fichier est commun aux langues « 
>> occidentales »),
> Ce n’est pas dans le but de heurter mais de sensibiliser que j’insiste pour opiner que 
> l’en_US.UTF-9/Compose — si c’est ce sur quoi on a planché en 2016 (cf. la liste non
> exhaustive de mails archivés, dans mon autre réponse) n’est plus du tout utilisable 
> dans des conditions correctes pour la prise en charge d’Unicode 10.0.0 = actuel.

Utilisable pour quoi?? On peut ajouter ce qu’on veut dans un Compose
personnel, et intégrer des combinaisons pertinentes dans le Compose
fournit par défaut — comme ce qui a été fait pour les touches mortes
monétaires et grecques d’ailleurs…

>> – la disposition dans /usr/share/X11/xkb/symbols/fr.
> Il doit certainement exister un script pour automatiser tout le processus de mise en 
> place lors de l’installation d’une nouvelle disposition téléchargée sur internet, comme 
> ce sera le cas du bépo 1.1 pendant un temps assez long (selon les informations ci-
> dessous), afin qu’il suffise à l’utilisateur de faire l’équivalent d’un double-clic sur un 
> setup.exe.

Oui et non. Le fichier sera écrasé lors d’une mise à jour, alors il
faudrait s’intégrer au processus de mise à jour de la distribution ce
qui est chronophage. Pour moi une meilleure solution serait d’ouvrir un
bug afin de voir s’il est possible de rendre plus simple le fait
d’ajouter une disposition au niveau du système (et également au niveau
utilisateur).

>> Ces fichiers sont potentiellement maintenus par des groupes de personnes 
>> différents, qu’il faut tous convaincre de l’intérêt de la demande (pour 
>> la version 1 du Bépo, plusieurs ajouts avaient été demandés, la plupart 
>> faits rapidement, mais ça avait patiné un peu pour le dead_greek), et 
>> pas forcément sur le même timing de sortie.
> Il n’est pas clair quelles réflexions menées sur les différents projets ont 
> conduit à faire l’impasse sur la personnalisation des dispositions de clavier, 
> car fournir toute disposition ayant émergé à un moment de l’histoire afin 
> de garantir une prise en charge maximale de toutes les préférences utilisateurs,
> mais en même temps compliquer la personnalisation de l’interface. On voit sur 
> internet des gens se plaindre de l’absence de documentation, et même si 
> plusieurs bonnes âmes en ont créé et partagé une, cela reste incomplet et 
> compliqué, un vrai truc d’initiés.

Encore une fois, tu accuses la mauvaise foi des développeur·se·s de XKB
alors que la raison simple, évidente, est qu’un tel niveau de
personnalisation n’était jusque là pas nécessaire et que personne n’a
donc pris la peine de le rendre possible.

On peut discuter de si XKB ou pas est pourri, en attendant ce n’est pas
le sujet.

>> Malgré tout, X.org contient la version 1 de la disposition Bépo depuis 
>> peut-être neuf ans, on attend toujours pour Windows et MacOS.
>> Mais si vous espérez que ça sorte le lendemain de la publication de la 
>> norme et sans effort de votre part, c’est optimiste…
> Des logiciels comme Firefox et Chrome aussi doivent être téléchargés sous 
> Windows et macOS, alors que Firefox est inclus dans Ubuntu comme Edge 
> dans Windows 10 et comme Safari dans Mac OS X. Or on ne peut nullement 
> tout faire ni dans Edge ni dans Safari, ni dans Firefox pour tout dire, donc
> on est tou·te·s amené·e·s [j’ai le point médian très facile] à télécharger 
> Firefox et Chrome ; et ce principe s’étend à une multiplicité de logiciels.

Tu fais des généralités sur des trucs qui n’ont absolument rien à voir,
tu t’en rends compte?

> Dans ces conditions, pourquoi Apple et Microsoft galèreraient-ils pour 
> fournir nativement toute disposition de clavier ayant acquis une existence, 
> au risque d’en oublier et de ne pas être à jour de versions ? À mon avis, 
> tant que les choses bougent — rappelons que le développement du clavier 
> français azerty permettant d’écrire en français est en cours depuis 34 ans 
> [je n’ai pas voulu écrire « trois quatre ans », mais « trente-quatre ans »] 
> et se heurte constamment à des gens qui croient mieux savoir et mettent 
> des bâtons dans les roues pour gagner plus d’argent sur le dos de notre 
> culture nationale — donc tant que les choses bougent, les éditeurs ne font 
> que dépanner leurs utilisateurs, à qui ils accordent la liberté d’ajouter 
> facilement mieux s’ils en trouvent ou s’ils viennent à en faire.

Clavier en développement depuis 34 ans? Qui sont ces gens qui se font de
l’argent sur notre culture nationale? De quoi tu parles?? Je ne
comprends même pas le sens de la dernière phrase. Tu utilises énormément
d’implicite sans préciser de quoi tu parles. Tout ça pour dire de façon
alambiquée que Windows ou macOS permettent plus facilement d’ajouter des
dispositions de clavier externes…

> La philosophie de Linux ne semble pas du tout la même. Ils ont l’air de 
> vouloir tout contrôler, tout valider en groupe de travail, ce qui les conduit
> à mettre en boutique tout ce qui a une existence publique ou historique, 
> sans doute dans l’idée que c’est le summum du service à l’utilisateur. 

Le développement de logiciels libre, c’est pas le milieu universitaire
ou de l’entreprise; la plupart des projets ne sont développés que par
une poignée de personnes, et ne possèdent certainement pas de groupe de
travail. Je ne comprends pas ta persistance à critiquer le développement
de projets dont tu ne connais visiblement pas le fonctionnement.

>> Ensuite, il faut encore que les distributions Linux mettent leurs 
>> paquets logiciels à jour, mais avant ça et plus ennuyeux, pour que ça 
>> fonctionne « out of the box » dans tous les cas, que les développeurs 
>> (notamment d’environnements graphiques) qui réinventent la roue en 
>> reprenant les règles de composition en interne plutôt que de faire appel 
>> à celles de X.org mettent à jour aussi.
> En fait ils (les développeurs d’environnements graphiques qui réinventent
> la roue) paraissent être arrivés à la même conclusion que moi quant à 
> l’utilisabilité du compose d’x.org, à moins qu’ils fassent double emploi.
> Face à la nécessité d’inclure des règles de composition pour tous les
> exposants et indices d’Unicode, changer plusieurs roues au carosse 
> en essayant d’en réinventer au mieux me paraît la meilleure option.

J’ai rien compris. Le soucis relevé est le suivant: GTK intègre ses
propres règles de composition qui sont les mêmes quelque soit la locale
(en effet, on utilisera la plupart du temps les règles définis pour
en_US.UTF-8, mais des règles particulières existent pour quelques
locales). Du coup quand on change des trucs au niveau système, GTK n’est
pas à jour.

Les développeurs de GTK ont reçu régulièrement des bugs au fil des
années à ce propos, et apparemment le seul truc qu’iels aient jamais
fait est de synchroniser leurs règles avec celles de X.org, au lieu
d’utiliser XIM et donc les règles du système directement.

>> C’est moins ennuyeux si c’est pour quelque chose de non indispensable…
>>
>> Du coup, pour que la disposition sorte rapidement, il peut être 
>> préférable de demander d’abord une version simplifiée dans 
>> xkb/symbols/fr et la version complète une fois qu’il y a ce qu’il faut 
>> dans keysymdef.h et Compose (même si ça rallonge le délai pour la 
>> version complète).
> Pourvu que les grand·e·s perdant·e·s de la realpolitik ne soient pas 
> les utilisat·eu·r·ice·s…

Si tu pouvais nous épargner tes invocations cryptiques et d’après ce que
je comprends hors de propos…

Attachment: pEpkey.asc
Description: application/pgp-keys