Balanced Keyboard Layout

[iandoug]

check commit logs for changes:
https://bitbucket.org/Shenafu/keyboard-layout-analyzer/commits/

currently KLAtest over-penalizes the thumbs. although my local version brings it back down.

At some point around Den 2 / Den 3 you started penalizing horizontal movements /and/or inside column on index finger... was that before Den 3 initial push?

[iandoug]

thus I made changes to your X8-3, which coincidentally also scored slightly better overall:

Thanks ... that G location was bothering me, I wasn't sure if I should fiddle or just leave it since results were generally good.

Need to see about the punctuation layer still.

Thanks, Ian

[iandoug]

thus I made changes to your X8-3, which coincidentally also scored slightly better overall:

Think I maybe found a bug in the scoring. In your X8.3 variant, if you swap the ? and {, then same-finger usage for left pinky goes up.

I would expect it to remain the same since it's the same finger, and words don't end on q or pipe char. I was testing with THE ECONOMIC CONSEQUENCES OF THE PEACE as input.

Possibly the use of the thumb Alt-Gr is confusing the calculation?

Thanks, Ian

[philippe.quesnel]

Massdrop has the Kinesis on special at USD300.

https://www.massdrop.com/buy/kinesis-advantage2-lf

I see that's around 400 CAD ... odd, I thought your currency was stronger than USD.

Thx, usually , with taxes, customs, shipping etc, the final price in $CAD is almost x 2 the original US price !!

[philippe.quesnel]

some new insights after testing new layouts.

feels better to start a bigram from the bottom row and end at top row than vice versa. it's related to how stretching feels better than curling, so that you end a bigram with a stretch rather than a curl.

thus I made changes to your X8-3, which coincidentally also scored slightly better overall:

Code: [Select]

X8-3A

qyou   vdrcz
hieaj  gtnsp
 x k   wmlfb


Interesting, will have a look, I started using X8.3 last weekend

[iandoug]

Thx, usually , with taxes, customs, shipping etc, the final price in $CAD is almost x 2 the original US price !!

Massdrop has X-bows on special now ...

[philippe.quesnel]

So I created ANSI "AngleZ" versions of some the layouts that looked good and I was interested in.
Interesting to see how some layouts translate well, while others don't.
For example, X8.3 was #1 among ergo kbd types, but did not do well as an ANSI layout. (?)

BEAKL15  was #2 (ANSI AngleZ version) and
#1 was a new layout I have been looking at : the BEAKL19.cfg applied to ANSI kbd with AngleZ ergo mod (running in AdNW opt).
They were pretty close of course.

BEAKL15 and BEAKL19 do very well with Jeanne (the only text I was have to test French, I have no idea if it is a good testing text or not)

BUT, I decided to try out X8.3 myself anyways .. and "Hey Mikey, I think he likes it" ! ;-)
Of course, I did a few personal / ANSI / 'requirements for French' small changes.
I'll look at Den's modifications, I am intrigued.

Oh, and about "currently KLAtest over-penalizes the thumbs", that also explains some results I was surprised with !

[philippe.quesnel]

Massdrop has X-bows on special now ...

Thank you. I did not know about massdrop ! Will have a look

[iandoug]

thus I made changes to your X8-3, which coincidentally also scored slightly better overall:

Thus I too made changes... :-)

Have not tried in real world, but after playing around most of day, attached does well as per current scoring on KLAtest. Dunno about the scoring on earlier KLAs.

For prose, from Part of the Resistance down to Phytochemical studies:

Category	Layout	1st	2nd
Prose	BEAKL 19	2	8
	Opted 4 Ergo Alt	3	2
	X8.3 a	1	14
	X8.3 b4	19	6

Essie won 2 and B15 won 3.

For the tests in most recent FinalList3 spreadsheet posted a few posts above,

Category	Layout	1st	2nd
Prose	BEAKL 19	1	1
	Opted 4 Ergo Alt	0	1
	X8.3 a	1	12
	X8.3 b4	13	2

Essie won 1.

For code, two top layouts alternated between Essie and Seelpy, generally followed by the BEAKLs.
So need to see how to borrow the good ideas there.

[Just to clarify, the 8.3a is variant Den posted earlier, made into json]

[iandoug]

Finally had the breakthrough I had been looking for all day.

Sometimes you need to throw caution to the wind and embrace the unthinkable ....

Does even betterer than previous .... probably time to bump the version number.

Enjoy.
Yes, left index does work a bit overtime.

Cheers, Ian

[philippe.quesnel]

Finally had the breakthrough I had been looking for all day.

Sometimes you need to throw caution to the wind and embrace the unthinkable ....

Does even betterer than previous .... probably time to bump the version number.

Enjoy.
Yes, left index does work a bit overtime.

Cheers, Ian

Cool. You guys are too fast for me, didn't have time to get use to X8.3 yet to feel the difference ;-)
a) Ooops, I'm running out of keys to adapt these ideas (was OK for one extra key, to place the stuff on SP, but now there are 2 thumb keys with chararcaters !)
b) Hey, cool you placed '^' right were I had it in my modified version, hehe, neat coincidence)
c) will have to think about how good an idea the Return on mid left index works for me with my "retarded keyboard" (aka normal keyboard ;-p)

I will try it out as-is on my SmartYao (have been trying it out again last weekend)

[iandoug]

@Den

Any idea how KLA handles tab character in text?

Just discovered it makes major difference to score between text having tabs, and having 4 spaces instead of tab.

Tabs also broke my "analyse text" program, will have to see how to fix that and make sure no other input texts have tabs.

Cheers Ian

[iandoug]

So tonight while busy with supper and pondering the B5 Bomber above, it dawned on me some of the reasons why code and prose tend to give different results on layouts....

1. short lines (this also applies to the "Quotes" input text). That means proportionally more use of Return key than in free-form prose. Which screws up the character distribution.

2. More use of non-alpha characters (but you knew that)

3. lots of spaces ... indentation etc. Which again screws up the character distribution. For KLA purposes all "indent by tab" gets replaced by "indent by spaces". And no "smart" thinking that maybe some divider lines were copy-pasted not typed.

4. Some of the code samples used have lots of CAPS.

5. Some of the code samples have lots of  "text/css" or "text/javascript" which produces an overload on the s-c same-finger which is not so prevalent in normal prose. By statistics in English, S is least likely to mix with C and F.

So choosing code samples carefully is going to be a more difficult problem than in English. Am open to suggestions/bright ideas :-)

Previous approach of grabbing a bunch of code off RosettaCode also led to the Tarzan/James Bond problem, eg the Luhn sample. Many of them used "luhn" which has two uncommon bigrams uh and hn.

[philippe.quesnel]

1) Any thoughts on the ergodox ez?

2) i have been trying out b5, was surprised about the zk swap.
the old k position was for me much more comfortable.
(under left index). It is good for French though.
I might just keep the old positions for English and the new one for french.
I had been trying to have a single layout for all languages,
but I think the small changes make it worth it to have two
oh, Enter on mid index row.. Not for me, on ansi kbd, the reflex to hit that old enter is just in my genes heje

[philippe.quesnel]

Oops, wanted to ask your thoughts on tenting and forward / backwards tilting and wrists reststhx

[iandoug]

Oops, wanted to ask your thoughts on tenting and forward / backwards tilting and wrists reststhx

We did discuss some of these things a while back here. In particular there is a paper done back in the 70s I think which will be relevant.
Will dig up the reference later ... need to go out now.

[iandoug]

Oops, wanted to ask your thoughts on tenting and forward / backwards tilting and wrists reststhx

Seen http://shenafu.com/smf/index.php?topic=89.msg2007#msg2007  ?

and
http://shenafu.com/smf/index.php?topic=89.msg2011#msg2011

PM me if you need further "help"....

[philippe.quesnel]

This came along:

http://www.x-bows.com/

Comments: Ian is not a gamer and does not care for flashing lights. Rather dump that and use the money for proper PBT keycaps, not ABS.
Unless you like "black and shiny".

Would also have preferred proper separation between left and right hand. I guess they're aiming at the gamer market, and wanted to keep the size down.

Also the ctrl-insert/shift-insert (copy/paste) right hand shortcuts look awkward. And no home/end... (that I can see), and I need those.

I like the space bar positions ... that's where I actually hit the thing, rather than the centre.

Hahal scrolling along below the 1st link you shared above for tenting etc, I see this! Good points (I am leaning more towards Ergo Dox right now, IF I do finaly get a real kbd)

[philippe.quesnel]

Seen http://shenafu.com/smf/index.php?topic=89.msg2007#msg2007  ?

and
http://shenafu.com/smf/index.php?topic=89.msg2011#msg2011

PM me if you need further "help"....

thank you ! (hehe, 'YOU' could be the nickname of X8.3b5.. so nice to type ...)

[philippe.quesnel]

Thou shalt....

Haha, can't help but laugh about this one :
" The de facto industry standard is the QWERTY (also known as the Sholes) layout.  Research indicates that keyboard arrangement is not necessarily the primary indicator of typing speed and there is no clear link between keyboard layout and user cumulative trauma disorders, therefore it is difficult to justify alternative keyboard layouts.  Additionally, some researchers have found that visual search time to locate keys is faster for QWERTY than for other arrangements"

[shopt]

bought a set of two SmartYao half-keyboards and was disappointed, I don't use them.

What were the problems that led you to stop using them?

[shopt]

1) Any thoughts on the ergodox ez?

I've been using one happily for almost a year. I do wish the thumb cluster was shifted "vertically down"; I need to twist my wrists to press the 3 upper keys in the thumb clusters. I haven't yet tried any concave keyboards, so I can't compare there unfortunately. The full split gives good arm angles, you can hot swap whichever switches you want, and being able to use QMK is a big plus. The cables that come from the factory are a bit cheap, but they are standard cables which you can substitute if you want. I wish the tent kit allowed for a steeper angle, and never had the wrist wrests (which are not very useful if you tent anyway).

[philippe.quesnel]

I've been using one happily for almost a year. I do wish the thumb cluster was shifted "vertically down"; I need to twist my wrists to press the 3 upper keys in the thumb clusters.

Thank you for the feedback.
I have to say I was thinking that only the two big thumbs keys seemed really usable, so I am not surprised about your comments.

For the SmartYao:
I got "two half keyboards" (vs a full kit that you can connect together) , otherwise you can only get staggered keyboard.
I had read that it still worked ok .. which is not completely true.

- on Windows pressing Alt on one keyboard and a key on the other did not work.
 And sometimes I was having other problems related to two keys on two keyboards

- it is "full matrix" (so not staggered at least ! ;-) .. which does not follow the natural fingers movements,
not as comfy as could be, especially since the rows are a bit 'tall' : 3 rows covers 3.5 rows of my microsoft kbd.

- no thumb keys, so using the thumbs is a bit limited (two is about ok though.
But the key caps are not so comfortable since you hit the key with the side of your thumb against the side of the key)

- needs wrist pads .. kbd is a bit thick, so not comfortable if hands are resting on the table

- if you use the tent kit, then keyboard is not flat, so it rocks a bit. (had to put pieces of paper under one corner to stop this)

- I thought I could program something like BEAKL on the kbd itself, ie including at least a punctuation layer.
I really wanted 3-4 layers on there.. But I could not do that.
For eg I could not program the shifted version of the key separately (ie 'a' will always be A when shifted .. so ',' '!' not possible on same key)
I ended up programming a QWERTY 'reference' layout and use AutoHotkey as with my normal kbd (plus 'thumb keys' though)

- Also, even if a key on one keyboard is programmed as RightAlt .. it just outputs Alt (same for other modifiers if I remember),
so I ended up using Numpad5 as an AltGr key for my thumb on the right keyboard.
Which means I could not use special combinations like AltL + CtrlR for hotkeys etc

- It does take more room with the separation, not much room for my mouse on the tray. (almost not usable)
In part because the connectors are on the side (or middle)
Probably a problem I will have with any good ergo kbd anyways.

I had fun rearranging the key caps to have a 'BEAKL' / 'home block' look though ;-p
Took a while to find this setup

[iandoug]

thank you ! (hehe, 'YOU' could be the nickname of X8.3b5.. so nice to type ...)

Yes I noticed... but also noticed the horrible RNL on the right side, which would make typing things like "the learner nearly learned" a real case of same finger abuse. I tried to find a better arrangement without success. Perhaps n-r and n-l is not as common in English as I think. Only the lonely.

Thanks for testing the B5, I appreciate the real-world feedback. (Also on the split keyboard above.)

FWIW, given that B5 ranks well on KLAtest, please remember:

1. Just because it ranks well does not mean it is the best layout .... the ranking is a combination of layout and scoring model, I just happened to find a layout that ticked the right boxes for the scoring model. A different scoring model would prefer a different layout.

2. That said, the letter positions are not entirely bad (based on many hours of doing this, as well as staring at what other researchers (academic and not) consider ideal layouts.

3. B5 is for English, in my humble opinion each natural language will require a different layout (although based on past testing, a layout good in English does OK on other languages with a reasonably similar vowel-consonant mix, and similar vowel-consonant structure (French does not qualify due to bizarre spelling and diacritics, Latin/Italian/Dutch and Southern African languages do, though "ij" in Dutch is sometimes a problem.)).

Had another point which escapes me now... will probably surface later.

[iandoug]

- I thought I could program something like BEAKL on the kbd itself, ie including at least a punctuation layer.
I really wanted 3-4 layers on there.. But I could not do that.
For eg I could not program the shifted version of the key separately (ie 'a' will always be A when shifted .. so ',' '!' not possible on same key)
I ended up programming a QWERTY 'reference' layout and use AutoHotkey as with my normal kbd (plus 'thumb keys' though)

- Also, even if a key on one keyboard is programmed as RightAlt .. it just outputs Alt (same for other modifiers if I remember),
so I ended up using Numpad5 as an AltGr key for my thumb on the right keyboard.
Which means I could not use special combinations like AltL + CtrlR for hotkeys etc

Are these issues not perhaps a side-effect of Windows keyboard driver? Or is the keyboard firmware sending the same scan code for both Alt keys?

AFAIK US Windows keyboards don't differentiate between the two Alt keys. If you have access to a tool (or a Linux box) that can print the scan code sent from keyboard then you can better see what is happening.

It's one of the issues I have with QMK is that it fakes being a US-ANSI layout to a degree. The Linux way is to take whatever scancode is sent and make it do what you want in XKB. On the other hand, QMK can do tricks that XKB cannot.

I tried QMK specific layout for my home-made board and could not get things like Function keys (which are on NumPad) to work ... so going to revert to having firmware say "I'm an ANSI" and send those scancodes, and let XKB do it's magic. I don't need the fancy QMK tricks at this point.

On the third hand, that approach won't work for Windows without something like AutoHotKey.

[philippe.quesnel]

Are these issues not perhaps a side-effect of Windows keyboard driver? Or is the keyboard firmware sending the same scan code for both Alt keys?

AFAIK US Windows keyboards don't differentiate between the two Alt keys. If you have access to a tool (or a Linux box) that can print the scan code sent from keyboard then you can better see what is happening.

I do use left vs right modifiers under Windows with normal US keyboards.
For example, to suspend my current AutoHotkey layout / script I hit Left Alt + Right Control, the sides do matter.

Also, leftAlt is currently the access key for the 'extend' / edit layer of my setup.

But yes, Alt on one kbd with a key on the another *does* work in Linux.

I am currently running Linux at home, I'll check the codes again to confirm ..
but it IS a problem with THAT kbd under Windows.

[ADMIN]

The file has fields separated by the tab character, opening this with something like LibreOffice calc is easy, don't know about Excel. Had to zip it because forum does not allow .tsv files.

Where VSV is pseudo-superset of TSV, and allowed here. Just start each line with TAB, save with extension .vsv, and upload it.

[iandoug]

Where VSV is pseudo-superset of TSV, and allowed here. Just start each line with TAB, save with extension .vsv, and upload it.

Looks powerful, will spreadsheet programs know what to do with it? (the extension .vsv itself, and the syntax of more complex files.

Curiously, I normally use tilde character for separating values in csv file, and the tablepress plugin on Wordpress handles that without even asking. It somehow figures out that the tilde is a separator instead of the expected comma.
LibreOffice allows user to select separator character via dialogue manually on such imports.

[philippe.quesnel]

Are these issues not perhaps a side-effect of Windows keyboard driver? Or is the keyboard firmware sending the same scan code for both Alt keys?
AFAIK US Windows keyboards don't differentiate between the two Alt keys.

Just tried it under Linux .. the programmed AltR and ShiftR (again, talking about two half SmartYaos matrix kbds) both output the same thing as the left ones ..
Tried with my normal kbd and I do see different scancodes.
I just redid a search and it is a known limitation of this product.

It's one of the issues I have with QMK is that it fakes being a US-ANSI layout to a degree. The Linux way is to take whatever scancode is sent and make it do what you want in XKB. On the other hand, QMK can do tricks that XKB cannot.

I tried QMK specific layout for my home-made board and could not get things like Function keys (which are on NumPad) to work ... so going to revert to having firmware say "I'm an ANSI" and send those scancodes, and let XKB do it's magic. I don't need the fancy QMK tricks at this point.

Hmm this is scaring me, regarding ErgoDox (which uses QMK).
I was under the impression this famous QMK was THE thing, really.
Now if it is not possible to do something 'simple' as programming a decent layout with some layers .. then I really can't justify almost $600 CAD and having the same basic limitation I had with the Koolertron. :-p
(ok, ok, they do have layers ;-)

I just had a look at their online configurator .. at 1st glance, just as with the SmartYao, it is not possible to select both main and shifted characters, you just select ONE character !
It has super fancy stuff but cannot do such basic things !!?? I just don't get it.

Probably would have to get into doing our own programming to do this?
Definitively need to do some research on this before dishing out the big bucks ;-p
(hmm, having a deja vu .. will do a search here on QMK)

[iandoug]

@philippe

Issues with QMK may be due to my limitations/ignorance, but I also had the problem with not specifying more than 1 letter per key ... hence why I was going to let Xorg handle that on Linux.

It's been a good few months since I last worked with it .... will try over weekend.

I think QMK was probably more aimed at working around Windows keyboard drivers.

Cheers, Ian

[philippe.quesnel]

@philippe

Issues with QMK may be due to my limitations/ignorance, but I also had the problem with not specifying more than 1 letter per key ... hence why I was going to let Xorg handle that on Linux.

It's been a good few months since I last worked with it .... will try over weekend.

I think QMK was probably more aimed at working around Windows keyboard drivers.

Cheers, Ian

ok thank you.
Have a nice Friday

[philippe.quesnel]

"The keyboard sends scancodes, not characters" ;-)
For some reason I tend to 'forget' how keyboards actually work ;-p

So, for example with '?'
it is really Shift + "the '/' key",
the OS decides to output '?' because of the configured kbd layout, could be anything actually
(as you all know, I know hehe)

So for us OS hoppers, it means double work for our special layouts, it does not seem to be really possible at the keyboard level.
Unless we stick to the traditional /? ;: mappings for shifted/non-shifted and just move keys around when programming the physical kbd... plus LAYERS, ahhh layers ;-)

[iandoug]

I do use left vs right modifiers under Windows with normal US keyboards.
For example, to suspend my current AutoHotkey layout / script I hit Left Alt + Right Control, the sides do matter.

Also, leftAlt is currently the access key for the 'extend' / edit layer of my setup.

But yes, Alt on one kbd with a key on the another *does* work in Linux.

I am currently running Linux at home, I'll check the codes again to confirm ..
but it IS a problem with THAT kbd under Windows.

According to Wikipedia (where I got the idea originally)
https://en.wikipedia.org/wiki/QWERTY#United_States

"The US keyboard layout has a second Alt key instead of the AltGr key " ... implying that some manufacturers may send the same scancode for both keys.

On my MS Natural, right alt is labelled "Alt" but acts as AltGr, certainly on the EUkeys layout on Linux, which implies that the scancodes are different. But I suspect cheap keyboards may be different.

Cheers, Ian

[sdothum]

Thought I would jump in here regarding QMK...

- AltGr (keycode 108) is defined and there are a number of macros to invoke it, the most common as RALT(keycode) -- there is supposed to be an alias ALGR(keycode) but I am not familiar with which #include file defines that (it is certainly easy enough to #define your own). You can also create more complex keycode sequences including the other modifier masks. NOTE: the QMK library of modifier macros that do not explicitly #define a "side" of the keyboard eg SFT_T(keycode), issue the left hand modifier keycode eg LSFT. In such instances you have to code your own macro if you need to distinguish the right hand keycode.

- Aside from applying conventional modifiers (eg Shift or Ctrl) to the remaining keys, custom layers are probably the most common approach taken for mapping alternate keycodes to the individual key positions, but you are not restricted to that mechanism only. You can do whatever you want with any keycode event e.g. transform Shift-keycode to be any other keycode (including any other modifier you want issued with that keycode) or even a string (or implement a calculator if you want).

The application of layers vs custom code is often simply a coding design choice -- layers do not take up a whole lot bytes -- depending on what you are trying to accomplish. Layers themselves may define modifiers to act on its layer and keys may raise subsequent layers. It all depends on the workflow you are trying to achieve. Modifiers, layers and custom code allow you to assign any number (effectively -- there may be a limit of 32 layers) of keycode values to a key position.

Being able to trap keycode events (both on the press and release) pretty much means you can make your keyboard dance to whatever tune you want. The beauty of a QMK flashed keyboard is that it is typically plug and play with any computer with no need to reconfigure the OS's keyboard settings.

Here's a write up on the Chimera Ergo 42 I will be building in the next couple of weeks to give you an idea...

http://thedarnedestthing.com/chimera%20ergo%2042

[iandoug]

You can do whatever you want with any keycode event e.g. transform Shift-keycode to be any other keycode (including any other modifier you want issued with that keycode) or even a string (or implement a calculator if you want).

Doesn't that still just send a scancode, eg say I have a ? as AltGr on the aA key, then QMK sends "altgr-A" (ie the scancode for aA assuming aA key is in normal QWERTY position, something like row-4-key-2) and it's up to the OS driver to decide what that actually means?

AFAIU QMK, it still sends scancodes because that's what the OS is expecting.... hence for the sort of layouts that we generate here, plug-n-play ain't gonna work?
Or am I severely misinformed? :-)

thanks, Ian

[iandoug]

@Den

Getting some weird results that bother me.

Tweaked the B5 a little to get better scores on KeyboardLayoutEditor (and hopefully HTML/JS in general), takes a small performance knock for most English, will see if I can work around that.

But I had Essie-3 in the mix, and noticed some weird behaviour.

On most English, Essie was around +- 30% worse than best layout. Except for Jonathan, where it beat B5/B6 by a few percent. Essies' same-finger is quite lower on JLS, but switch to The Little Prince and then Essie's same-finger falls between Maltron and Colemak ... which makes no sense. Surely tests on English should produce results largely congruent with each other?

If you switch to the code tests, eg Towers of Hanoi A-M, then suddenly Essie is +52% better than next best, with dramatically lower same-finger.

So is this a quirk or something?

B6 attached. Subject to change :-)

[iandoug]

Getting some weird results that bother me.

Use this as input:

Code: [Select]

<s
<t

<b
<d
<h
<l
<p

<o
<a
<u
<i


1>
2>
3>
4>

i>
e>

v>
p>
l>
">
'>
g>
d>

And see same-finger for MTGap.

Makes no sense .... :-)

[sdothum]

Doesn't that still just send a scancode, eg say I have a ? as AltGr on the aA key, then QMK sends "altgr-A" (ie the scancode for aA assuming aA key is in normal QWERTY position, something like row-4-key-2) and it's up to the OS driver to decide what that actually means?

I am not sure I quite understand your example. First off, there are no default key position values. So you can define for example on your base layer row-4-key-2 to be any keycode, eg "J". Another key may be defined as ALTGR (RALT) on down. So when you press ALTGR (and hold) then tap "J" and release ALTGR, the OS keyboard driver will see ALTGR (down), J (down), J (up), ALTGR (up). Similarly, you could define a layer with a key position defined using RALT(KC_J) to issue the same sequence. This is similar to how letters are capitalized with the Shift modifier (in terms of how the key sequences are issued by the keyboard.) Perhaps, I am missing something with regards to how ALTGR is generally interpretted -- I don't use it to type special characters. So yes(?), your OS driver needs to interpret the keycode sequence.

But, if the question is, can you type "a" -> "a", and "AltGr-a" -> "?". YES, you can do that quite easily with QMK. There are two obvious ways to accomplish this, depending on your layout needs.

If you are merely using ALTGR effectively as a mechanism to assign a set of alternate key values to a bunch of key positions in your layout, you can simply desigate a key to raise a layer with your set of alternate key values. It doesn't in this case have to be ALTGR because it's not being used to issue ALTGR -- you can simply define MO(altlayout). Layout tables are cheap to implement (in terms of memory space).

If you need ALTGR but for some keys you don't want ALTGR issued (as described above) and instead just want to issue an alternate keycode, within QMK you can hook into the keycode processing loop and achieve what you want. In this case, on your row-key keycode value (as defined in your layout table eg KC_A), if ALTGR is down (somewhere else in your processing loop, the ALTGR state needs be set/unset), unregister ALTGR (because it is in a down state), register and unregister your desired alternate character, register ALTGR (to restore the down state for subsequent processing), else do something else (eg pass through, etc). It sounds messy but by defining a function it's not a whole lot of effort to implement this for your set of use cases. The keyboard output stream will contain ALTGR (down), ALTGR (up), new keycode. The down/up ALTGR effectively do nothing.

Is this what you are trying to accomplish?

[iandoug]

I am not sure I quite understand your example. First off, there are no default key position values. So you can define for example on your base layer row-4-key-2 to be any keycode, eg "J". Another key may be defined as ALTGR (RALT) on down. So when you press ALTGR (and hold) then tap "J" and release ALTGR, the OS keyboard driver will see ALTGR (down), J (down), J (up), ALTGR (up).

....

If you need ALTGR but for some keys you don't want ALTGR issued (as described above) and instead just want to issue an alternate keycode, within QMK you can hook into the keycode processing loop and achieve what you want. In this case, on your row-key keycode value (as defined in your layout table eg KC_A),

That is exactly the problem ... they keyboard does not send an "A" .. it sends a scancode for A as defined on a ANSI QWERTY keyboard.

It's up to the OS to interpret that ... for example it may interpret that as a B instead, because your logical layout has been defined to have a B on that key.

Well that's how I understand how QMK operates.... hence my comment earlier about it faking being an ANSI QWERTY board to the OS.

xev reports this from my MS Natural (QWERTY) keyboard when pressing a A

KeyPress event, serial 37, synthetic NO, window 0x8e00001,
    root 0x296, subw 0x0, time 296720562, (-126,627), root:(1065,1079),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x8e00001,
    root 0x296, subw 0x0, time 296720698, (-126,627), root:(1065,1079),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x8e00001,
    root 0x296, subw 0x0, time 296721791, (-126,627), root:(1065,1079),
    state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x8e00001,
    root 0x296, subw 0x0, time 296721991, (-126,627), root:(1065,1079),
    state 0x11, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XmbLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x8e00001,
    root 0x296, subw 0x0, time 296722165, (-126,627), root:(1065,1079),
    state 0x11, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

[iandoug]

Had to change desks.

New desk has sharp edges. Hurts my forearms.

Trying desktop hack. Made from pool noodle.

More gentle on forearms, but now arms are much higher off keyboard ... will have to get used to it for a while I suppose.

[sdothum]

That is exactly the problem ... they keyboard does not send an "A" .. it sends a scancode for A as defined on a ANSI QWERTY keyboard.

It's up to the OS to interpret that ... for example it may interpret that as a B instead, because your logical layout has been defined to have a B on that key.

Well that's how I understand how QMK operates.... hence my comment earlier about it faking being an ANSI QWERTY board to the OS.

xev reports this from my MS Natural (QWERTY) keyboard when pressing a A

I must be having a senior moment. You have completely lost me.

xev from my splitography which has row-2-col-4 defined as "A"

KeyPress event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92507274, (197,329), root:(892,347),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92507275, (197,329), root:(892,347),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92530303, (197,329), root:(892,347),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92530645, (197,329), root:(892,347),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XmbLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92530647, (197,329), root:(892,347),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2400001,
    root 0x16b, subw 0x0, time 92531019, (197,329), root:(892,347),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

So you don't want this? I can plug this onto a Windows/OSX/Linux box and produce "aA" leaving all systems with their defaulted US keyboard.

I am very confused as to what you are trying to emulate.

[sdothum]

So for us OS hoppers, it means double work for our special layouts, it does not seem to be really possible at the keyboard level.
Unless we stick to the traditional /? ;: mappings for shifted/non-shifted and just move keys around when programming the physical kbd... plus LAYERS, ahhh layers ;-)

Did my previous post clarify that you are *not* limited with QMK to mapping / -> /, Shift-/ -> ? and can map (via coding) Shift-/ to effectively output any scancode sequence including any combination of modifiers (which can exclude Shift) you require? I have been doing this on my BEAKL layout variants but it does require going beyond simply defining a bunch of keyboard layers (arrays of key values).

EDIT: as an alternate approach to modifiers eg Shift, you can also assign a key as a pseudo Shift whereby it raises a layer on down. You could populate that layer with eg S(KC_A) for uppercase "A" and the parent Slash key position with an unshifted keycode eg KC_EQL "=" or a different Shifted (or any modifier sequence for that matter) keycode eg S(KC_4) "$" . The Shift as modifier is a convenience for creating Shift scancode *sequences* but you can explicitly define that sequence as a key on a layer. The beauty of this approach is you are still just defining layers with no custom macro coding but achieving the effect of a Shift modifier key.

Advance apologies if I am demonstrably off track in this thread..

[philippe.quesnel]

Did my previous post clarify that you are *not* limited with QMK to mapping / -> /, Shift-/ -> ? and can map (via coding) Shift-/ to effectively output any scancode sequence including any combination of modifiers (which can exclude Shift) you require? I have been doing this on my BEAKL layout variants but it does require going beyond simply defining a bunch of keyboard layers (arrays of key values).

Ok, thx, that's what I did understand .. and it confirms what I was thinking : I need to get into coding, using the online Configurator will not be sufficient.
I did think about just considering the shifted main layer as .. well, just another layer and using another key to access the layer (ie NOT Shift)

For now, this is just me asking questions, I don't have a kbd to try this out / never did anything w. QMK, I was asking because I realized that the ErgoDox works w. QMK and I am thinking of getting an ErgoDox kbd ;-)

Oh, I guess the possible solution you explained in the end is about the same to what happens when using AutoHotkey on Windows,
If I want to send '; 'on Shift-Q, it (or my code!) will send Shift Up to release shift before sending ';' and then send back Shift down to restore its down state...

[sdothum]

Oh, I guess the possible solution you explained in the end is about the same to what happens when using AutoHotkey on Windows,
If I want to send '; 'on Shift-Q, it (or my code!) will send Shift Up to release shift before sending ';' and then send back Shift down to restore its down state...

Yes, if you wish to use the hook within QMK I described to trap the Shift-Q event sequence. Otherwise a dedicated layer can do that with less coding effort. It all depends on how you wish to design your firmware. There are many ways to achieve the same outcome in QMK. Tables are so cheap (bytewise), oftentimes layers can be more expedient than coding custom functions. And you can do things with QMK that are simply not possible with an off-the-shelf keyboard solution -- such as, some of the chords described in the Chimera layout that are very specific to my workflow, not to mention the advanced QMK macros such as TapDance.

[iandoug]

So you don't want this? I can plug this onto a Windows/OSX/Linux box and produce "aA" leaving all systems with their defaulted US keyboard.

I am very confused as to what you are trying to emulate.

:-)
Okay, you confirm my point that QMK works by faking that it is a US ANSI keyboard. (which, as an aside, is not "the Linux way").

So it pretends you are pressing what would be "a" on US ANSI, regardless of where it actually is on the keyboard.

Now what happens when you're in Canada and you define the normal letter on a key to be é . That does not exist in US ANSI, so what does QMK send?

Your description matches how I understood QMK's intentions to be ('we can do anything", more or less) and yes it can tap dance and do backflips, but at the end of the day it's still faking being a US ANSI when it comes to sending scan codes.

In my case, building the X6.5h (https://keyboard-design.com/letterlayout.html?layout=x6-5h.en.ergolinear) I had issues getting the Function keys to work. This may have been because of XKB (I "Included" other default components including Function keys, and tried to redefine them in XKB mappings by putting them on the numeric shift, but didn't work) rather than QMK. There may also have been some other issue, can't remember now, tried to have another look over the weekend but other stuff got in the way. Will try again during week).

When I looked at it I got very confused by the QMK documentation .... they really need a better Big Dummy's guide for us newbies. With lots of simple examples. At the time I though their config method was unnecessarily complex and there had to be a simpler way, maybe that's not possible if you want to to backflips.

I see I redid QMK to think it's running on a mostly-ANSI layout, so my problems probably lie more at the XKB end.

Will revert. Else I need to put aside time to become more of an expert on QMK. Trying to get away with learning only what I need to learn ;-)

 

[sdothum]

Okay, you confirm my point that QMK works by faking that it is a US ANSI keyboard. (which, as an aside, is not "the Linux way").
So it pretends you are pressing what would be "a" on US ANSI, regardless of where it actually is on the keyboard.

I guess my senior (as in citizen) brain is having difficulty with the term "faking" an ANSI keyboard (and *not* the "Linux way"). The way I look at it is, there is a "specification" defining the key or scancodes at the interface which the driver at the other end for whichever OS interprets as "whatever", be it a printable character, modifier, function key, hardware setting (eg sound volume), etc. to pass onto the OS/application. This specification defines the ANSI interface.

QMK complies (this is semantics but I do acknowledge I can be reading impaired at times :-) with that specification, the actual keyboard layout of which is totally arbitrary -- all keyboards are wired in principle in the same way, row by column through a microcontroller which allows one to define the scancode to be issued when any particular row-col key is depressed and released, the sequence of which (thinking mainly modifier keys here) is interpretted by the OS keyboard driver (eg "Shift-a" -> "A").

As for Canadian-French keyboard, I do not correspond in French nor have such a keyboard, but regardless (correct me if I am wrong), that keyboard still must pass at the physical interface, the appropriate scancode *sequence* to the OS's French language driver. The language specific keyboard simply defines in firmware specific keystroke chords which, when received, produce the proper scancode sequence for the special characters of that language as recognized by the OS keyboard driver.

All OS keyboard drivers are limited by the physical interface and its set of scancodes as defined in this USB spec https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf (see page 53).

I am not a subject expert in this. If I am off base, I suggest you post a question on the r/olkb forum https://www.reddit.com/r/olkb/, many members of whom are maintainers of QMK and, therefore, better versed in the subject -- I just use QMK and have not examined to any great extent the code at the microcontroller/USB level. Failing to get a satisfactory response from there, you could also post a question in the github/qmk-firmware issues.

As for XKB and the use of xmodmap to alter the keymap on the X11 side, that seems to me to be a lot of unnecessary and undesirable effort (you'd have to apply those changes to every machine you expect to connect your keyboard to), when you could easily issue the Fn keycodes from the keyboard, the whole point of QMK. This should also be a lot easier to debug without mangling the scancodes at the driver side (but I have only ever used this route minimally during my early Colemak tweaking days with a commercial keyboard.. :-)

Sorry I can't be of any more help if my limited understanding does not answer your post.. I just use QMK and have not found it lacking.

[iandoug]

@Den

Playing with code samples, including COBOL, some of which use A LOT OF CAPS.

That produces weird results on KLAtest.

for example, MTGap and Maltron suddenly did the best.

So ran a test using short sample text. Compare results using

Code: [Select]

My interest in keyboard layouts came after I read a Discover magazine article entitled "The Curse of QWERTY". The article tells the story of the QWERTY and Dvorak keyboard layouts and makes a compelling case for switching from a QWERTY layout to a Dvorak layout. Here is a quick summary of its most important points:

    The QWERTY layout was created in the early 1870's before touch typing and without speed or comfort in mind.
    The Dvorak layout was created in the 1930's and is based on years of research. It takes speed and comfort into account.
    On average, the left hand does 56% of the typing when a QWERTY layout is used. With a Dvorak layout, the right hand does 56% of the typing.
    The Dvorak layout forces you to alternate hands more frequently when typing, this causes you to type faster.
    Users type fastest on the home row. With a QWERTY layout, only 32% of your typing occurs on the home row. With a Dvorak layout, 70% of your typing occurs on the home row.
    It's hypothesized that the Dvorak layout will make it less likely that you'll develop Carpal Tunnel Syndrome (CTS).
    Anecdotally, people who develop carpal tunnel syndrome seem to find relief when they switch from a QWERTY layout to Dvorak layout.

There are more reasons, but those were the ones that stuck with me. I was so convinced by what I read that I switched my work and home keyboard layouts to a Dvorak layout by configuring some Windows XP settings in the control panel (to see how click here). This lasted for about 6 days (3 of those were over the Labor Day weekend), and then I had to switch back since learning the Dvorak layout was slowing me down at work. I also discovered that the Dvorak layout made all the nice QWERTY keyboard shortcuts (Undo, Cut, Copy and Paste) virtually unusable. This was a big minus since I use those shortcuts constantly. The Dvorak layout also over worked my right pinky. I found myself having to take typing breaks, something I hadn't done since high school.

After talking to someone who had Carpal Tunnel Syndrome (something I'm worried about getting), I learned about yet another improved keyboard layout that preserved QWERTY's bottom row short cuts and didn't put massive amounts of stress on the right pinky. This layout was known as the Colemak. Unlike the Dvorak, the Colemak layout is relatively new (developed within the last 5 years), doesn't have a lot of research behind it, and it doesn't have a very large following (online estimates put the number of users between 650 and 1,300). However, the layout looks pretty promising.

All of this research is what motivated me to create this application. I wanted to visually compare my typing patterns with the different layouts and get some stats on what hand and which fingers I was using the most.

Hopefully the user interface and output is straight forward enough. I had a lot of fun writing this application, hopefully some of you out there will find it useful.

vs

Code: [Select]

MY INTEREST IN KEYBOARD LAYOUTS CAME AFTER I READ A DISCOVER MAGAZINE ARTICLE ENTITLED "THE CURSE OF QWERTY". THE ARTICLE TELLS THE STORY OF THE QWERTY AND DVORAK KEYBOARD LAYOUTS AND MAKES A COMPELLING CASE FOR SWITCHING FROM A QWERTY LAYOUT TO A DVORAK LAYOUT. HERE IS A QUICK SUMMARY OF ITS MOST IMPORTANT POINTS:

    THE QWERTY LAYOUT WAS CREATED IN THE EARLY 1870'S BEFORE TOUCH TYPING AND WITHOUT SPEED OR COMFORT IN MIND.
    THE DVORAK LAYOUT WAS CREATED IN THE 1930'S AND IS BASED ON YEARS OF RESEARCH. IT TAKES SPEED AND COMFORT INTO ACCOUNT.
    ON AVERAGE, THE LEFT HAND DOES 56% OF THE TYPING WHEN A QWERTY LAYOUT IS USED. WITH A DVORAK LAYOUT, THE RIGHT HAND DOES 56% OF THE TYPING.
    THE DVORAK LAYOUT FORCES YOU TO ALTERNATE HANDS MORE FREQUENTLY WHEN TYPING, THIS CAUSES YOU TO TYPE FASTER.
    USERS TYPE FASTEST ON THE HOME ROW. WITH A QWERTY LAYOUT, ONLY 32% OF YOUR TYPING OCCURS ON THE HOME ROW. WITH A DVORAK LAYOUT, 70% OF YOUR TYPING OCCURS ON THE HOME ROW.
    IT'S HYPOTHESIZED THAT THE DVORAK LAYOUT WILL MAKE IT LESS LIKELY THAT YOU'LL DEVELOP CARPAL TUNNEL SYNDROME (CTS).
    ANECDOTALLY, PEOPLE WHO DEVELOP CARPAL TUNNEL SYNDROME SEEM TO FIND RELIEF WHEN THEY SWITCH FROM A QWERTY LAYOUT TO DVORAK LAYOUT.

THERE ARE MORE REASONS, BUT THOSE WERE THE ONES THAT STUCK WITH ME. I WAS SO CONVINCED BY WHAT I READ THAT I SWITCHED MY WORK AND HOME KEYBOARD LAYOUTS TO A DVORAK LAYOUT BY CONFIGURING SOME WINDOWS XP SETTINGS IN THE CONTROL PANEL (TO SEE HOW CLICK HERE). THIS LASTED FOR ABOUT 6 DAYS (3 OF THOSE WERE OVER THE LABOR DAY WEEKEND), AND THEN I HAD TO SWITCH BACK SINCE LEARNING THE DVORAK LAYOUT WAS SLOWING ME DOWN AT WORK. I ALSO DISCOVERED THAT THE DVORAK LAYOUT MADE ALL THE NICE QWERTY KEYBOARD SHORTCUTS (UNDO, CUT, COPY AND PASTE) VIRTUALLY UNUSABLE. THIS WAS A BIG MINUS SINCE I USE THOSE SHORTCUTS CONSTANTLY. THE DVORAK LAYOUT ALSO OVER WORKED MY RIGHT PINKY. I FOUND MYSELF HAVING TO TAKE TYPING BREAKS, SOMETHING I HADN'T DONE SINCE HIGH SCHOOL.

AFTER TALKING TO SOMEONE WHO HAD CARPAL TUNNEL SYNDROME (SOMETHING I'M WORRIED ABOUT GETTING), I LEARNED ABOUT YET ANOTHER IMPROVED KEYBOARD LAYOUT THAT PRESERVED QWERTY'S BOTTOM ROW SHORT CUTS AND DIDN'T PUT MASSIVE AMOUNTS OF STRESS ON THE RIGHT PINKY. THIS LAYOUT WAS KNOWN AS THE COLEMAK. UNLIKE THE DVORAK, THE COLEMAK LAYOUT IS RELATIVELY NEW (DEVELOPED WITHIN THE LAST 5 YEARS), DOESN'T HAVE A LOT OF RESEARCH BEHIND IT, AND IT DOESN'T HAVE A VERY LARGE FOLLOWING (ONLINE ESTIMATES PUT THE NUMBER OF USERS BETWEEN 650 AND 1,300). HOWEVER, THE LAYOUT LOOKS PRETTY PROMISING.

ALL OF THIS RESEARCH IS WHAT MOTIVATED ME TO CREATE THIS APPLICATION. I WANTED TO VISUALLY COMPARE MY TYPING PATTERNS WITH THE DIFFERENT LAYOUTS AND GET SOME STATS ON WHAT HAND AND WHICH FINGERS I WAS USING THE MOST.

HOPEFULLY THE USER INTERFACE AND OUTPUT IS STRAIGHT FORWARD ENOUGH. I HAD A LOT OF FUN WRITING THIS APPLICATION, HOPEFULLY SOME OF YOU OUT THERE WILL FIND IT USEFUL.


[iandoug]

Hi

Attached zip file with some code samples for keyboard testing. They should be better than the current batch.

General idea:
1. find code for various languages
2. should be different authors and styles
3. should avoid the Tarzen/James Bond problem
4. should be different lengths.

So I scavenged RosettaCode again, for selected languages. Basically generally took the first example for each letter of the alphabet, pasted all into a language-specific file. There will be some "Tarzan" overlap between files, but should not be within each file. Files were cleaned a bit where necessary to ensure all typeable on US ANSI.

Some languages historically used ALL CAPS for reserved words (eg COBOL or IBM 360 assembler) but modern samples seem to use more lower case.

I have kept Carriage Return in the frequency analysis, all Tabs in samples were converted to 4 spaces.
Usually put 2 or 3 blank lines between samples, sometimes with a few spaces in them (blame my editor for that).
The exercise reminded me how little I love COBOL and Javascript (and R would join that list if I used it... :-) )

The Javascript samples are plain vanilla JS, none of the JQuery or Angular syntactical monstrosities.

Still need a solution for HTML/CSS. At present just keeping KLE until I get inspiration.

Am open to suggestions re languages and/or methodology.

Letter frequency order for all the code samples is:

et[ENTER]inraosld)(,c0up-.=m1fh";gbyx2:v_{}Rw'*S+[]I>/<EATL3kCN94O5DP86$MF7BqzG!j&UHVW\%|#XY@K?ZQJ`^~

"Enter" was previously between n and r until the last few languages (Julia and R, if I remember correctly), which pushed it higher.

In general, the three chars `^~ are hardly ever used, only Haskell and R use all three, the other languages may use one or two but not all three. Which kinda makes me wonder why they decided to put tilde on the keyboard in the first place. I've posted the char counts at the end.

Language choices:

Widely used / popular:
* C
* C++
* C#
* Java
* Javascript
* Perl
* PHP
* Python
* Ruby

Upcoming:
* Go
* Haskell
* Julia
* Kotlin
* Lua
* R
* Rust

Corporate/Legacy:
* Ada
* COBOL
* Fortran
* IBM 360 assembler


Analysis:
Spreadsheet attached.
They all do poorly when compared to English character frequency, as is to be expected.
Even the top 11 chars do poorly, the best (COBOL) gets a score of 37 out of 66.

On the positive side, some languages supply all 96 chars, and most of the others in the 90s.

I'm a bit puzzled myself as to how to use this for evaluating a keyboard, since the letter and punctuation orders are so different to English.
One the one hand, English optimization is more important, but English does not allow us to decide best positions for rest of keys .... any inputs / ideas here welcome.

Have also attached one of latest X8 series layouts, as well as another English text from John Ward, which does reasonably well in suitability for our purposes. Please note text selections are based on suitability for our tests and not on content/ideas/opinions of texts, which is mostly irrelevant for our needs.

Cheers, Ian

All char frequencies in code samples:
space 383289
e       55368
t       44150
ENTER   39311
i       39118
n       38863
r       36174
a       31796
o       31252
s       30450
l       22817
d       18938
)       17817
(       17805
,       17491
c       16961
0       16890
u       16495
p       14848
-       14326
.       14190
=       13701
m       13406
1       12377
f       12196
h       10949
"       10114
;       9570
g       8772
b       8084
y       6793
x       6771
2       6683
:       6082
v       5646
_       5447
{       5354
}       5349
R       5251
w       5002
'       4973
*       4960
S       4867
+       4796
[       4796
]       4720
I       4673
>       4627
/       4572
<       4414
E       4261
A       4238
T       4132
L       4017
3       3997
k       3889
C       3865
N       3838
9       3690
4       3566
O       3279
5       3229
D       3065
P       2958
8       2756
6       2681
$       2552
M       2337
F       2298
7       2154
B       1888
q       1814
z       1678
G       1598
!       1528
j       1452
&       1432
U       1403
H       1309
V       1180
W       1174
\       966
%       938
|       919
#       852
X       846
Y       812
@       596
K       574
?       445
Z       442
Q       428
J       322
`       151
^       151
~       60

[philippe.quesnel]

...
I'm a bit puzzled myself as to how to use this for evaluating a keyboard, since the letter and punctuation orders are so different to English.
One the one hand, English optimization is more important, but English does not allow us to decide best positions for rest of keys .... any inputs / ideas here welcome.
...

Wow, hard at work again Ian ! ;-)
For the question you asked (quote above) .. one thing I tried in the past when creating 'Seelpy' style layouts, was to do a pass for the main layer and a separate pass for the punx / syms. I guess in this case a different set of data could be used to optimize the secondary layer?
How to then test in KLA is another queslion

[ankt]

Hey

Can you upload your kb layout so I can mess with it? : D