|
je complète avec une demande de Jean Z
(lors de la discussion sur le verr maj):
- rendre accessible le remappage du clavier
la Le 27/10/2016 à 20:32, Piyou a écrit :
Bonjour,
Est-ce que la définition de la norme comprend aussi la manière
dont la disposition est intégrée au système d'exploitation ?
- possibilité de choisir dès l'installation de l'OS
- possibilité de choisir lors du démarrage d'une session
(pratique quand on est plusieurs à partager un ordi et tt le
monde n'est pas bépoète)
- accès à la configuration aisée, choix de la langue puis de
la disposition
- accès à un clavier virtuel, (pratique pour saisir les mots
de passe qd on n'a pas le bon clavier)
- harmonisation des raccourcis clavier pour passer d'une
dispo à l'autre
Merci à ceux qui prennent le temps de participer aux réunions
avec l'Afnor
Le 27/10/2016 à 16:47, Marcel a écrit :
Voici
pour rappel en vrac et à toutes fins utiles les questions
sur
http://bepo.fr/wiki/Discussion:Version_1.1
posées
à l’intention de l’Afnor :
•
Et qu’il faudrait demander à l’AFNOR si l’on change le sort
actuellement
réservé à la lettre-apostrophe (qui se trouve
aujourd’hui
en latin+apostrophe).
•
Concernant la variante en A, on est d’accord qu’on part sur
un développement
d’une
version séparée, et qu’on demandera le point de vue de
l’AFNOR avant de
trancher
si on en fait quelque chose d’officiel ou pas ?
--Milton
(discussion) 29 août 2016 à 12:25 (CEST)
•
Premièrement, l'apostrophe-lettre est utilisée en breton (et
ça devrait aussi
être
le cas en anglais si l'on en croit [ce lien]). Or le breton
est une langue de
France,
et notre travail s'inscrit dans le cadre de la normalisation
AFNOR, qui a
pour
but de définir un clavier pour toutes les langues de France.
Donc il est
pertinent
d'avoir l'apostrophe-lettre en accès vif.
Pour
des raisons mnémotechniques, il est intéressant de regrouper
ce caractère
avec
les autres apostrophes. […]
--Thomas
30 août 2016 à 10:43 (CEST)
•
Ce sont nous les implémenteurs, il n’y aura pas de problèmes
sur la présence de la couche latin étendu.--Flavien21
(discussion) 30 août 2016 à 16:51 (CEST)
Je
me permet de mettre un bémol sur ce point, l’AFNOR nous a
fait comprendre qu’il n’y a que les caractères qu’Elle aura
listée qui devront figurer dans les documents de
normalisation. Si le drivers que vous préparez est plus
complet tant mieux mais les développeurs sur les différents
OS se limiterons à ce qu’il y a dans les documents de
normalisation, avec une forte probabilité que tout ce qui
n’est pas en carte de base (+Shift, Alt-Gr et Shift+Alt-Gr)
puisse être déplacé au petit bonheur la chance — tant que
c’est accessible d’une manière ou d’une autre. La notion de
Couche Latin étendu, Arabe et autres n’apparaitra pas dans
la norme et risque de n’exister que dans votre driver.
Serait il possible, lors de la prochaine réunion avec
l’AFNOR, de soulever ce point afin que cette notion de
couche puisse apparaitre dans la norme ? Elivagar
(discussion) 10 septembre 2016 à 21:05 (CEST)
Cette
liste devrait être soumise à l’enquête publique comme tout
le reste. Couper les ailes aux claviers de France en les
filtrant par ce jeu partiel insuffisant relèverait de
l’inconscience. Après des décennies de laisser-aller et de
temps de réflexion — je sais que les gens rigolent ! — les
Français ont vraiment droit à quelque chose
d’hyper-performant.
Puis
comme déjà dit par d’autres, les implémenteurs c’est nous,
ce sont les proposants. Les éditeurs d’OS majeurs n’auront
plus qu’à apposer leur griffe (à supposer que Mac OS et
Linux soient capables de faire la même chose que Windows !).
Marcel (discussion) 10 septembre 2016 à 22:11 (CEST)
Marcel,
les accès d’emphase mélodramatiques n’apportent rien au
débat, restons sobre et précis.
L’AFNOR
sélectionnera la liste des caractères présents dans la
normes en fonction de ce que ses interlocuteurs
(entreprises, collectivités, associations) lui demanderont
d’y placer et elle demandera de justifier la présence de
chacun des nouveaux caractères. Quant à savoir si Ergodis
sera l’implémenteur, cela dépend de Microsoft, s’ils peuvent
utiliser le driver développé par Ergodis — cela permettrait
d’outre passer la norme dans la liste de caractères
disponible dans la disposition — ou si ils vont se sentir
obligé de faire leur propre version — et là, seul les
caractères de la normes seront intégrés (et pas forcement en
utilisant les couches supplémentaires proposés ici).
Elivagar (discussion) 11 septembre 2016 à 00:31 (CEST)
Il
en ressort qu’il est primordial de développer le driver
Ergodis pour Windows en utilisant l’outil Microsoft, le
« Keyboard Table Generation Tool (Unicode) v3.40 ». Par
conséquent, il faut programmer le driver en C [toutefois, au
prix de certaines limitations, il est aussi configurable
dans un fichier .klc]. Sur dispoclavier.com, tout le monde
peut télécharger des exemples/modèles de sources (j’en ai
aussi mis sur GitLab mais c’est trop galère pour moi) ainsi
qu’un script en batch qui fait tourner KbdUTool. Ce dernier
est gratuit. Il est inclus dans le MSKLC. Toutes ces
informations sont aussi données par le script (qui s’appelle
CreaKbd-fr).
En
démocratie (comme d’ailleurs dans tout autre système
politique), il y a naturellement beaucoup d’irrationnel qui
entre en ligne de compte. Le prendre en considération, c’est
rester réaliste. Objectivement, la démarche DGLFLF-AFNOR est
inefficiente, puisqu’ils n’ont pas pris comme point de
départ le jeu de caractères spécifié par la norme
internationale ISO/IEC 9995. Partir du MLS leur aurait déjà
évité de commettre la gaffe la plus symptomatique :
l’impasse sur le SIGNE MOINS U+2212. C’est une parfaite
illustration de la tournure prise par le processus de
normalisation laissé à lui-même. Heureusement, les
responsables ont l’intelligence de mener une enquête
publique bien avant la publication des normes de
dispositions de clavier. Marcel (discussion) 11 septembre
2016 à 05:34 (CEST)
Elivagar,
ce n’est pas du tout ce que j’ai compris. Dans la plaquette
envoyée par l’AFNOR avec la liste des caractères, il est
explicitement précisé que les caractères de la norme
pourront être placés en touche morte. Si jamais le BÉPO
normalisé tel que défini à l’issue de ces concertations
place la lettre apostrophe en {touche morte latin étendu} →
{apostrophe}, et si la touche morte latin étendu est
attachée à la position AltGr+T, alors un éventuel autre
implémenteur n’aura pas le choix. Le seul risque est que les
caractères hors-norme passent à la trappe, ainsi bien sûr
que les couches ne contenant que des caractères hors-norme
(soit, si je ne m’abuse : le cyrillique, le grec étendu et
les mathématiques). ☺|☻ Bien à toi --Milton (discussion) 11
septembre 2016 à 08:28 (CEST)
Ce
que je lis du document AFNOR-CN35-GT1_N26_Reunion Couverture
des signes.pdf envoyé le 9 Juin par JC Groult sur la mailing
list , c’est que les caractères doivent être accessible pour
que la disposition proposée corresponde à la norme, à aucun
moment il est dit que les touches mortes seront normalisées,
nuance. De mon point de vue, outre la carte de base (ce qui
sera effectivement gravé sur les touches), tout le reste
sera à la discrétion du développeur (touches mortes, couches
supplémentaires,…). C’est peut-être réducteur comme
interprétation mais cela nous donnera des questions
supplémentaires à poser lors de la prochaine réunion avec
l’AFNOR pour éclaircir ces zones d’ombres.Elivagar
(discussion) 11 septembre 2016 à 16:09 (CEST)
La
moitié des caractères de la couche latin étendu faisant
partie de la norme (dont la lettre apostrophe), ils seront
bien inclus. Pas de soucis à se faire --Flavien21
(discussion) 11 septembre 2016 à 16:19 (CEST)
Le
lien a trouvé les exceptions pour l’usage de la lettre
apostrophe – contraction de « not », dans les noms propres —
il a oublié de parler du cas possessif « ʼs », mais dans
tous les autres cas comme dans « They’re » ou « He’s » (qui
n’est pas du possessif dans ce cas) c’est bien une
apostrophe simple et sépare deux mots. Il se contredit avec
ses exemples du français.--Flavien21 (discussion) 30 août
2016 à 14:56 (CEST)
Il
y a peut-être des approximations dans son raisonnement, mais
ça ne change rien à notre sujet :-) --Thomas (discussion) 30
août 2016 à 15:20 (CEST)
Je
rejoins Flavien sur le fait que je doute que la couche latin
étendu soit zappée. Elle contiendra plusieurs des caractères
imposés par la norme, et ce ne sera pas la seule touche
morte non diacritique (il y a déjà le dead_currency et le
dead_greek, demain dead_api, dead_cyrl, dead_math). À mon
avis, la principale chose qui puisse justifier un passage
sur la couche principale, c’est la logique (par exemple,
toutes les lettres de l’alphabet latin sont en accès vif, on
ne va pas en mettre une en morte) et la visibilité que l’on
accorde à un symbole (d’où ma proposition pour le copyleft).
Ici, il me paraît en plus plus ergonomique de faire AltGr+T
puis apo que AltGr+Maj+Apo, mais je puis me tromper.
--Milton (discussion) 30 août 2016 à 18:26 (CEST)
Je
propose de laisser le sujet de côté pour le moment.
Peut-être que la question pourra être abordée lors de la
prochaine réunion avec l'AFNOR, et que nous aurons alors
plus d'éléments pour décider: l'AFNOR aura peut-être
elle-même une solution, et il sera pertinent de mettre les
deux claviers (azerty et bépo) en cohérence. --Thomas
(discussion) 30 août 2016 à 21:00 (CEST)
> Message du 27/10/16
16:18
> De : "Jean-Christophe Groult" <jcgroult@xxxxxxxxx>
> A : "discussions" <discussions@xxxxxxxxxxx>
> Copie à :
> Objet : [EGD-discu] Réunion AFNOR
>
>
Bonjour,
>
> La réunion afnor aura lieu demain, mais je
n’ai toujours pas l’ordre du jour, donc je ne peux
pas vous dire de quoi on va parler.
>
Au mois de juin, il était question d’écrire le
premier brouillon de la norme, et pour cela une
journée entière était prévue.
>
Comme cette réunion a été réduite à 3 heures, je
suppose que ce n’est plus l’objectif (ou alors pas
toute la norme?).
>
J’enverrais un compte rendu demain.
>
A+
>
>
LeBret
>
|