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

[ Thread Index | Date Index | More ergodis.org/discussions Archives ]


Le 04/05/18 12:17 Mélanie Chauvel (ariasuni) écriva :
[…]
> 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à.

Surtout parce qu’il est incapable de produire nativement plus d’une unité de code UTF-16 par touches mortes.

[…]
> Ç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.

L’économie de travail fait partie des économies d’échelle, qui elles ne sont pas essentiellement 
morales, mais économiques, obéissant à des lois auxquelles nul d’échappe. 

Ce qui caractérise les bonnes économies d’échelle, c’est qu’elles sont faites au bon bout.

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

Si la règle devient que chacun doit d’abord redessiner le compose à sa convenance, 
fournir un compose préinstallé sera devenu de moins en moins utile.

Utilisable pour quoi, je l’ai écrit, pour Unicode actuel dont par exemple les exposants et 
les indices. Fusionner exposant avec circonflexe et indice avec macron a été une décision 
de courte vue au niveau d’un compose qui se veut Unicode. Les premières lettres en 
exposant sont dans Unicode depuis le début. Mais comme le début officiel d’Unicode fut 
en 1992, il postdate la fondation du compose.

[…]
> 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).

Oui fais-le s’il te plaît, file un bug. Pour qu’un fichier ne soit pas écrasé, le mieux 
est qu’il porte un nom distinctif, peu susceptible d’être utilisé lors des mises à jour.
Par exemple "Français France Ariasuni".

[…]
> 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.

Je comprends subitement que les gens qui avaient besoin de dispositions de clavier 
spéciales n’utilisaient pas Linux. La NSA travaillait sous Windows et se tourna vers 
Microsoft :

http://archives.miloush.net/michkap/archive/2013/10/04/10454264.html

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

Que toi aussi discrimines les dispositions de clavier aide à comprendre que des gens 
puissent consommer des tas de logiciels sans sourciller, mais faire la fine bouche 
devant un simple driver de disposition parce qu’il n’a pas un beau plumage ni une 
belle voix.

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

Préempter le travail des journalistes n’est pas mon rôle. J’avais donné quelques éléments 
et ne les répéterai pas maintenant. Cela n’a que peu à voir avec les OS, et beaucoup avec 
des gens en France, je l’ai dit, qui ne se préoccupaient pas des préférences des utilisateurs,

[…]
> 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.

Canonical doit être quand même une grosse boîte, ils avaient certainement 
les moyens d’émuler Windows, l’ont peut-être fait ou pas, en tout cas il n’y 
a pas que les petits groupes de volontaires sur ces projets. D’ailleurs Google 
ChromeOS utilise XKB aussi, avaient-ils juste la flemme de le mettre à niveau, 
avec toute la puissance de Google derrière et un peu de bonne volonté ça y 
serait, et toutes les distributions Linux auraient pu en profiter. 

Ou alors ils se disaient que ChromeOS et le reste de l’XKB sont uniquement 
pour des gens peu demandeurs, les autres prenant Windows ou macOS. 
Alors oui on comprend l’état de relatif abandon où ça se trouve.

[…]
> > 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.

GTK n’set pas le problème et je n’ai même pas compris pourquoi ils font 
double emploi si c’est pour se laisser dire qu’ils peuvent aussi bien utiliser Xorg.

Le carosse est le compose surchargé qui frôle la panne, un vrai vieux clou.
Les roues à réinventer sont des règles de composition.

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

Je n’ai rien compris, mais de nouveau, GTK n’est pas le cœur du problème.

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

Si les développeurs d’XKB sont juste un peu paumés, je les épargnerai.

Par contre pourquoi épargner le projet bépo qui promeut sciemment une 
disposition nettement sous-optimale sous prétexte qu’il a fallu des claviers 
imprimés, sérigraphiés ou gravés dans le plastique ou le marbre, et que 
maintenant c’est tant pis pour les millions d’utilisateurs à acquérir ?

@Nicolas : j’y reviendrai.

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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/