Re: [EGD-discu] Usages informatiques

>> 1) Soit il est trop tard et les choses restent en l’état, d’autant plus qu’un vote
>> a eu lieu. La garantie est donnée que « ^ mort » + espace permettra toujours
>> d’obtenir le circonflexe pour la programmation.

>D’où vient cette garantie ? C’est obsolète. Implémenter Unicode, c’est aussi
>faciliter l’accès aux diacritiques combinants. Donc, comme déjà exemplifié par
>d’autres et répété x fois : touche morte - espace ➔ diacritique combinant, et
>exit les caractères informatiques par détours.

ok soit, « ^ mort » + espace n’est plus une option pour obtenir « ^ ». Mais alors j’espère que « ^ mort » ne restera pas sur AltGr + « 6 ». La compatibilité ANSI me semble être l’un des atouts de la disposition par rapport à l’AZERTY, y compris pour les split-keyboards avec « 6 » à droite.

>> 2) « ^ vif » (celui du « 6 ») est déplacé sur la position du « ≠ ». C’est une
>> suggestion de Marcel, suite à mon premier message sur le sujet. « ≠ » est inutile
>> en programmation puisqu’il n’est pas un caractère du QWERTY US.
>> Cette solution a deux avantages:
>> - (Vraiment) utilisable sur ANSI vis à vis des 5 exemples non exhaustifs que j’ai
>> énumérés (en plus du Typematrix)
>> - Justifie le maintien de AltGr+Shift+Ê (car AltGr + touche de gauche est
>> préférable à AltGr + touche — possiblement — de droite) et donc ne remet pas en
>> cause un vote.
>
>Personnellement je ne proposerais à AUCUN informaticien d’accéder à l’un ou
>l’autre caractère informatique UNIQUEMENT en Maj + AltGr.

Ce commentaire fait donc référence au point 3, pas au point 2. La position actuelle du « ≠ » s’obtient sans appui sur Maj.

J’établis la hiérarchie d’accès suivante:

Accès direct > Accès en Maj > Accès en AltGr + touche de la moitié gauche > Accès en AltGr + Maj d’une touche de la moitié gauche > Accès en AltGr + touche de la moitié droite, sauf « 6 » ou « 7 » > Accès en AltGr + Shift de la moitié droite sauf « 6 » et « 7 » > Accès en AltGr + « 6 » ou « 7 »

Je fais des combinaisons en Maj+Alt et Maj+Ctrl+Alt (QWERTY US) à longueur de journée ce qui est confortable pour moi tandis qu’AltGr + « 6 » ou « 7 » me dérangerait énormément. Certes je n’aurais qu’à taper « 6 » de l’index gauche si le clavier est ANSI (et si j’utilisais le bépo dans un contexte professionnel), mais certains utilisateurs peuvent utiliser un split-keyboard incompatible.

Si chaque caractère US peut être placé soit en accès direct, soit en Maj, soit en AltGr + moitié gauche en conservant la carte de base, alors ce sera une grande avancée pour le bépo !

J’ai insisté sur le « ^ vif » car son positionnement me semble aberrant, tout comme le « | » ou le « ` mort » sur Azerty historique français. Je n’ai pas du tout suivi les discussions de diacritiques combinants (sauf lorsque j’ai parlé de ÍJ́) et je ne me vois pas abandonner Qwerty US pour coder car j’ai besoin de touches Alt symétriques.

Bon courage pour la suite.

Le 18 décembre 2016 à 16:47, Marcel <bkn.ema@xxxxxxxxx> a écrit :

Le 18/12/16 13:40, Merlin Vedeux a écrit :
> […]
> Au final:
>
> 1) Soit il est trop tard et les choses restent en l’état, d’autant plus qu’un vote
> a eu lieu. La garantie est donnée que « ^ mort » + espace permettra toujours
> d’obtenir le circonflexe pour la programmation.

D’où vient cette garantie ? C’est obsolète. Implémenter Unicode, c’est aussi
faciliter l’accès aux diacritiques combinants. Donc, comme déjà exemplifié par
d’autres et répété x fois : touche morte - espace ➔ diacritique combinant, et
exit les caractères informatiques par détours.

>
> 2) « ^ vif » (celui du « 6 ») est déplacé sur la position du « ≠ ». C’est une
> suggestion de Marcel, suite à mon premier message sur le sujet. « ≠ » est inutile
> en programmation puisqu’il n’est pas un caractère du QWERTY US.
> Cette solution a deux avantages:
> - (Vraiment) utilisable sur ANSI vis à vis des 5 exemples non exhaustifs que j’ai
> énumérés (en plus du Typematrix)
> - Justifie le maintien de AltGr+Shift+Ê (car AltGr + touche de gauche est
> préférable à AltGr + touche — possiblement — de droite) et donc ne remet pas en
> cause un vote.

Personnellement je ne proposerais à AUCUN informaticien d’accéder à l’un ou
l’autre caractère informatique UNIQUEMENT en Maj + AltGr.

[…]
> Le 17 décembre 2016 à 16:40, Laurent > […]
> > Heureusement, bientôt le Bépo sera /enfin/ meilleur que l’Azerty pour les
> > langages informatiques :

C’est loin d’avoir été le dernier mot sur l’AZERTY. Probablement cette réunion
n’aura été qu’un tour de chauffe. Attendez un peu et vous verrez peut-être les
propositions pour l’AZERTY pleuvoir. Trois mois d’enquête publique ! Voire avant.

> >
> > Le 2016-12-16 à 20:05, Valentin Melot a écrit :
> > > […] sur toutes les solutions étudiées, l’apostrophe droite (') et les guillemets
> > > droits (") seraient accessibles EXCLUSIVEMENT par les touches mortes
> > > aigu et trémas, suivies d’une saisie sur espace..
> >
> >
> > Enfin attendons quand même de voir où ils placent <, , $, etc. avant de crier
> > hem… « victoire » (par jeu contre son camp de l’adversaire).

Très juste. Le projet bépo ne saurait sainement se reposer sur ce qui a pu se
passer avant-hier en réunion.

> >
> > Bon, la majorité des informaticiens conservera probablement l’Azerty historique
> > ou passera au Qwerty… comme maintenant.

Si le bépo n’améliore pas de manière rigoureuse et radicale l’accessibilité d’un
certain nombre de caractères informatiques, et l’ergonomie des ponctuations hautes
(correctement saisies évidemment), et différents autres points déjà discutés, le
bépo est mort à mon avis. Car en plus de l’azerty amélioré, il y aura probablement
l’asertuniop’, et du coup encore moins de monde verra l’intérêt de s’embêter pour
apprendre le bépo. Je ne sais pas comment vous vivez le fait d’avoir sur le projet
l’un des possibles futurs architectes du nouvel azerty. Quant à moi j’ai toujours
cru que c’est un avantage. Comme ça vous avez certaines infos de première main.

Par exemple tout à l’heure j’ai fini les 2 premiers groupes du mode Français de
l’azerty automatisé que je vais bientôt mettre en ligne (pilotes pour Windows) :

http://dispoclavier.com/#i0

Maintenant c’est bardé de caractères informatiques doublés, même en mode Français.
Et toutes les lettres additionnelles sauf l’œ sont relégués dans les autres groupes.
Pourquoi ? parce que sous Windows, on ne peut pas utiliser les niveaux AltGr sur les
lettres, il y a souvent des ennuis, c’est connu. Et la bascule VerrCap ne fonctionne
pas dans le groupe 2 s’il n’est pas en AltGr. Donc il n’y a plus aucune paire de
lettres bicamérales, toutes sont dans les groupes 3 et supérieurs, même l’æ. Et
l’eszett. Car j’ai *enfin* compris qu’il est impossible de le faire fonctionner
comme il faut autrement.

Pourtant il y a déjà un équivalent pour le bépo, depuis octobre sur le wiki :

http://bepo.fr/wiki/Utilisateur:Marcel/Version_2.0

Sur le bépo actuel, c’est différent, on fait de la discrimination entre l’œ/æ/ù
d’une part, et désormais l’ß, l’ĳ et les autres d’autre part. Et comme en plus,
sur le bépo on est *obligés* d’avoir le groupe 2 en AltGr (à cause du tout-en-
capitales avec des Œ et des Ù), autant y laisser l’ß, l’ĳ et le ə, pensais-je.
Le bépo étant assigné à carte simplifiée, on n’a donc plus la possibilité de revoir
son fonctionnement. Mais avec le groupe Latin et ponctuation, Flavien et Miltøn
ont créé le moyen de faire de la place sur la carte !

C’est cette chance qu’il faudrait maintenant saisir pour améliorer l’ergonomie
de l’utilisation du bépo en informatique. Les informaticiens sur cette liste
ont prévenu très tôt dans l’année que si le bépo ne tient pas suffisamment compte
de leurs besoins, le bépo pour eux est mort, en quelque sorte.

Comme Laurent nous le rappelle dans ce fil… On se répète encore et encore, car
a-t-on vu dans les derniers votes un seul d’entre ces informaticiens lanceurs
d’alerte ? Il me semble qu’ils se soient tous abstenus. Ne se voyant pas entendus,
ils laissent le bateau bépo partir à la dérive.

Il reste deux mois pour agir.

Marcel

--
Pour ne plus recevoir les messels de cette liste de discussion, envoyez un messel avec pour destinataire discussions-REQUEST@ergodis.org et pour sujet "unsubscribe".