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

[Marcel <bkn.ema@xxxxxxxxx>]

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.

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…

> – 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.

> – 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.

> 
> 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. 

> 
> 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. 

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.

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. 

> 
> 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.

> 
> 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…

Marcel

--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".