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