For reference, and for @fishheadsoup, that discussion is here.
As some pointed out, my earlier post was way too specialized.
I think the way forward is for us all to step back and agree on a base. Once weāve done that we can discuss the finer points.
From reading through again, I think the following is a fair assessment of the consensus so far:
Iāve left alone the top row, centre keys, palm keys, and thumb arcs to be the same as the qwerty default, since from the default qwerty thread it looks like these are the parts which J&K are most keen on staying common between the different default layouts. Iāve shaded these grey.
Iāve shaded other keys green. These, I think, are the ones which must be this way for a US Dvorak keyboard, at least in their top-level and shifted cases. I donāt think we have any arguments about these, until possibly we get to the function layer, but letās leave that alone for now.
Iāve left the other six keys white, and filled in just two, which have pretty much unanimously been agreed upon: the /? and the -_.
Missing but vital are:
- Cursors
- The `~ key
- The | key
- The =+ key
- Square brackets
- Curly braces
- F11 and F12
Missing and arguably vital are
- Page up and down, home, end, insert, delete
Keeping those missing things in mind but not worrying about them yet, can we agree on the above as a base to build on?
5 Likes
Good job, thanks bjn.
How often would people use LED? Which Iām guessing toggles backlit on/off. Iām guessing (for me at least) that it wouldnāt be used as often, maybe turn on and leave on, then turn off and leave off. I propose moving LED to Num or Prog.
1 Like
Well what Iām trying to do here is avoid making arbitrary changes from the default qwerty layout for āextraā keys such as LED and prog and and num.
Go take a read through the default qwerty thread which I linked, in particular Jesseās posts. Iām just trying to find a lowest common denominator here.
Having said that, I asked just now over in that thread whether those shaded-grey keys accurately reflect what Jesse would ideally like to stay the same between layouts. If he says no, Iāll of course adjust as necessary and we may have more room to play.
Based on @bjnās template, I would think something like this:
http://www.keyboard-layout-editor.com/#/gists/88b03f9777fc1e62d9471b9d41c835f8
(with the arrow keys on the āDHTNā keys in Fn layer as QWERTY)
Edit: also assuming that itās feasible to have ā{ā and ā}ā mapped to Fn-Shift-R/L
This is an absolute basic minimum for dvorak touch-typists, so yes I would strongly agree.
Now we have four white keys left to put five standard keys on. Of course, if we could reuse the Prog key for something else after boot (as was suggested earlier in one of these threads) that gives us one more key. I know itās not easily touch-typable but letās face it, the equivalent key on pc105 isnāt exactly easy to reach either.
LED currently walks through a variety of LED color effects. LED, Any, Prog and Num are all keys that require a relatively large stretch to hit. Thatās why theyāre all mapped to keys that are not things you would touch type.
Of all of them, Prog[ram] is the only one thatās really, really special. That key has a second physical behavior. Itās hard-wired to pins on the main microcontroller. Itās used during boot to determine if itās safe to go into the bootloader. (As a guard against malicious remote flashing.)
You could remap it to something else, but I think it would not be the best idea.
Youāve put `~ in the top left ā I like that. Itās the same as the default qwerty layout, which is probably a good thing, and is in a similar position to where probably all keyboard users expect it to be.
Youāve put =+ left of A, but it looks like you have + as the un-shifted one and = as the shifted one. Was that on purpose? Iām assuming this was a slip and you meant to have = unshifted and + shifted. With that assumption, I like this placement too. Itās far away from where the key usually is on an old Dvorak board, but it very nicely mirrors the -_ key ā minus on one side, plus on the other. I think this would be easyish to get used to.
You have | in the bottom right. This is the same hand as US Dvorak on a 104-key keyboard, which is probably good, though below the home row rather than above. I type on UK Dvorak on a 105-key keyboard and for me | is in the bottom left. That means your proposal is the same row and finger as Iām used to (though on the other hand), which for me is a positive. So I think it seems reasonable for both 104-key and 105-key keyboard users, and so it seems reasonable.
You have page up/down in the bottom left. Were you imagining one would be on the function layer, or shifted, or what? I wonder if shift-(pgup/pgdn) is ever needed for anything? If so, shifted would be no good. I suspect you meant it to be on the function layer, though. It seems reasonable. How would we decide which one out of pgup and pgdn is on the base layer and which isnāt? Iād suggest leaving pgdn on the base layer. My reasons are twofold: in normal usage (think browsing the web) pgdn is probably used slightly more than pgup, and this would make pgdn in the same position and layer as on the default qwerty layout.
What do you think of switching pgup/pgdn and |? This would put | exactly where 105-key keyboard users like me are used to it being, but moves pgup/pgdn to the opposite side from the Model 01 qwerty layout. Given that your proposed position changes the pgup/pgdn from qwerty in putting them both on the same key anyway, Iām not sure how big of a deal that is. But the argument against my suggested swap would be the mouse-in-right-hand, paging-with-left-hand argument. So I think itās likely best as youāve put it.
You have the square brackets on function-R/L, and braces on shift-function-R/L. I suggest instead doing the same thing as the currently published default qwerty layout and having the braces instead on function-G/C. This would mean less chording, and also more things in common between the layouts.
As Iāve said before Iād personally like the cursors engraved on the J, K, H, and L keys, but this is an unpopular opinion so Iāll drop it. Instead, cursors, for layouts without HJKL in a row, as Iāve been suggesting in the default qwerty layout thread, should be on CHTN (Dvorak right-hand home-position inverted-T). Ahhh, but this clashes with where I just suggested we put the right brace. And so I suggest instead that the braces are on F and G. (I would suggest having the braces on the left side to mirror the square brackets, but this is where it looks like the convention is suggesting the mouse movement keys are, and so I doubt itād fly.) Iāve gone and suggested in the qwerty thread that this is the convention for all layouts which donāt have bigger ideas (including qwerty), but Iāve no idea if anyone will like that idea.
I think itās reasonable to put F11 and F12 in the same spots as in the qwerty layout, which is on the rightmost two home row keys.
After all this I have something like the following (editable):
Any strong opinions here? Whoās on board, who isnāt?
Still missing:
- Home
- End
- Insert
- Delete
I have some ideas for these, but before that I would like to see if we can again come to a consensus. One step at a time!
3 Likes
Yup, that was indeed a slip.
That seems reasonable, I could be convinced either way.
Agreed.
I think it was proposed somewhere that Fn-Backspace would be Delete?
to your proposed layout.
Shift-page keys are used in Linux terminals for the scrollback buffer. Quite important.
I donāt see any problem with putting both page keys in the fn layer. The palm fn keys make it quite possible to find them one-handed, so long as you put them under the index finger.
Ah yes, of course ā I indeed use shift-page in terminals windows myself sometimes. Though the question about shift-page becomes moot if using the function layer for pgup anyway.
Iām not against both page keys being on the function layer. Do you have a suggestion for something to use in the base layer on that key instead?
Iād prefer to have all us-ascii printable keys on the base layer, so would be my choice. But you canāt do that without replacing at least one of Prog or Num also.
OK, how about this? I have moved the brackets keys to the base layer left of A and moved =+ to where Num usually is. I know this breaks the Qwerty equivalence of the grey keys, but moving Num lets us do a cool trick.
We can then have two Num keys, one for each hand. That means we can use one to toggle a left-handed numpad and one to toggle a right-handed one (left-handed numpads are quite useful for people who use right-handed mice, see the numpad thread). The Num toggles are in the Fn-layer rather than the base layer, but if we want two Num toggles weād have to do something like that anyway.
Iāve also added both left-handed and right-handed navigation. We can use one set of arrows for mouse keys and the other for keyboard arrows, and have the handedness configurable.
http://www.keyboard-layout-editor.com/#/gists/ad811203b1048d065d61453228932b84
I donāt like having the +/= keys so inaccessible, given how often theyāre typed when programming.
Jesse was pretty keen on keeping everything shaded grey the same between default layouts, so Iād agree that the =+ shouldnāt be in that top right corner. Having said that, that would somewhat approximate its position on a standard keyboard in Dvorak.
The [{ and ]} seem awkwardly placed to me. What makes you so keen to have them on the base layer? I would have thought the palm keys are easy enough to use that having [{]} in more accessible places (though on the function layer) would be preferable. I wonder if @jesse could chime in regarding the palm keysā ease of use?
Because if {} are not on the base layer, then they have to be implemented with a (potentially leaky) kludge. See @algernonās explanation in message 77 above.
I like the layout as proposed by @andrewg. The main thing Iām missing is something that could function as a numpad on my right hand because I tend to use that quite a bit. Since youāve duplicated most of the Fn keys on both the left and right side, hereās my take on it with a numpad on the right-hand side.
http://www.keyboard-layout-editor.com/#/gists/846ba5f3b5adde6c8fe814e4cb748c6e
As discussed somewhere else (Iām losing track of all these threads) the numpad layer is a separate one from the Fn layer, and is initiated using the Num key as a toggle (this is distinct from the pc105 numlock). I didnāt put the numpads on that last layout because it was already crowded.
I read this thread only, but Iām pretty sure I read all of it. Mustāve missed it 
In that case, never mind, your layout looks fine to me.
Jesse doesnāt seem to think itās a problem, given that the current plan for qwerty is for {} to be on the function layer. And then I canāt imagine it being a problem for Dvorak typists if itās not for qwerty.
1 Like