Re: [EGD-discu] Votes ?! |
[ Thread Index | Date Index | More ergodis.org/discussions Archives ]
Ce qui est noté ∉ n’est pas le caractère en lui-même, mais davantage l’enchaînement de touches mortes maths+barré. Pouvoir le faire par maths puis barré ou barré puis maths ne change pas grand chose?d qui est associé à ∉ (je ne vois pas son intérêt ici, sa place est sur la touche symboles scientifiques) Sauf abus de ma part, on risque d’avoir un problème similaire pour beaucoup de touches mortes. La création de nouvelles touches mortes et de nouveaux comportements pour celles-ci ne plaira sans doute pas, vu que le système de composition de X.org est assez peu adapté à ce que l’on cherche à en faire. Mais je pense qu’une fois la norme publiée, on aura un assez bon argument pour qu’ils acceptent de créer cette locale. ^^Donc d’une part l’ajout d’une nouvelle touche morte ne me semble pas un problème insurmontable. D’autre part, demander la modification d’une touche que l’on a nous même poussé initialement ne me semble pas incohérent. Au pire, si on essuie un refus sur ce dernier point pour la raison que l’on modifie un comportement déjà établi, raison que je comprends très bien, il doit être possible de demander la création d’un nouveau compose, dédié non pas au bépo, mais au français. En effet, la locale fr_FR.UTF-8 utilise le compose en_US.UTF-8. On pourrait donc demander la création d’un compose spécifique fr_FR via fork du compose en_US existant, et y surcharger le comportement du dead_stroke pour *quatre* caractères. Cela n’impacterait plus que les utilisateurs français. Reste à voir comment gérer les autres locales francophone. Au pire, on fourni une définition de compose spécifique pour que les utilisateurs puissent surcharger la définition système au niveau utilisateur. Ça parait moche ? Le bépo 1.0 a pourtant fonctionné sur cette base pendant un certain temps. -- Miltøn |
Attachment:
signature.asc
Description: OpenPGP digital signature
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |