It's the keyboard layout.

[_wb_]

I like the progress, and I have a feeling ED wants only one meta label per key. (It would be nice to know his preferences, but on the other hand he didn't ask us to work on this either...)


My comments/concerns with _wb_'s latest and greatest:

http://www.keyboard-layout-editor.com/#/layouts/448795011aec0eda1781efb5cd9ea44f


1. I like the symmetry between {}[]/|\. To me it really helps guide the eyes towards the symbols. In my own layouts I also try to have patterns, though I have also been trying to keep things like ü on Meta+U.


2. I appreciate the "breakthroughs" on diacritics. I think we can all benefit from them, especially if we get the Neelix(?)-suggested keyboard Mea+GUI popup going.

Thanks!

3. At one point I thought about switching = and +, so there's a symmetry of (-=+). I think it's a net gain for the code-combos score. (It lowers i++, but gains -= and increases /=.) Here's an alternative rearrangement of yours which increases the code combos quite a bit, though it may look a little less symmetric to some:

http://www.keyboard-layout-editor.com/#/layouts/73a832d97d3d555a888dee767649badb


(Nice subtle symmetries: operator opposites are vertically two keys apart.)

I see your points and I like the subtle symmetries (and the fact that * + / - are in one 'column'), but I prefer to have - and + next to eachother, for programs where they're used for something like zooming in and out or adjusting something. Also maybe for the Compose sequence to produce ±. Minus on the bottom row deviates quite a bit from its expected position.

The symmetry -=+ makes sense in the same way as <=> makes sense. Still I prefer to have -+ and <> as neighbor-pairs.

4. Concern: I would prefer keyboard Meta and Shift to be on the right (switching places with , and .), for the following reasons. This has a nice symmetry of putting all diacritics on the left side of the board. It also makes it possible to easily do a shift+meta+button for any key on the left side of the keyboard, which would be the more common side of the keyboard to do both modifiers on. (Like with Shift+Meta+Tab for Grave, and Shift+Meta+F for Ä.) It would also raise the code combo score (you get <= and >= for free).

You are right, Shift and Meta on the right makes more sense. Comma and period on the left is not the normal position, but 1) it's the same as on the Pandora, 2) it means they can be on the same row, eliminating the ugly jagged positioning (especially ugly for < >), 3) it puts the diacritics together like you say, and 4) it makes ' " look less out of place.

For people who don't use shoulder buttons, it makes the coding symbols slightly less practical (you have to use sticky Meta and then symbol, both with right thumb, while if Meta is on the left, both thumbs can be used). But I suspect that most coders will prefer to use the shoulder button modifiers anyway.

For natural language, Shift on the right makes sense because QWERTY is left-biased. And for diacritics that require Shift+Meta (grave, tilde, umlaut, caron, circumflex) and for capital version of the precomposed Ü Ö Ä ẞ É È À Ç Ñ it helps too, like you said.

5. Very small concern: { Enter is a very painful code-combo, so you penalize C/C++ peeps .

It is not that painful. While Y is slightly on the right so you would normally use right thumb, it should be rather easy to hit it with left thumb. After all, it is only half a key away from the center.

In http://www.keyboard-layout-editor.com/#/layouts/8e2043b67cc1b33225d69686868dc76dI think ?_=;: could be moved around and I'm not sure which way I like best.

 

[_wb_]

In http://www.keyboard-layout-editor.com/#/layouts/8e2043b67cc1b33225d69686868dc76dI think ?_=;: could be moved around and I'm not sure which way I like best.

Maybe this is more or less optimal: http://www.keyboard-layout-editor.com/#/layouts/2cc807dd1656a0703fb8bf12f074357f

 

[FaeMinx]

In http://www.keyboard-layout-editor.com/#/layouts/8e2043b67cc1b33225d69686868dc76dI think ?_=;: could be moved around and I'm not sure which way I like best.

Maybe this is more or less optimal: http://www.keyboard-layout-editor.com/#/layouts/2cc807dd1656a0703fb8bf12f074357f

Hey this layout is awesome! (Haven't really examined a layout since Grench's initial dosbox one.)


You guys have done an amazing job... it's wonderfully to see a lot of the best concepts each of you championing coming together so elegantly.


Also, the tone of this thread the last week or so has really made me proud of this community. Admittedly I've still been skimming, but after this layout I'm now keen to check out the other front runners.


It's feeling close. How many are there now?


I could get behind this layout, but maybe the others are just as good?


Love the number and F1-12 implementation.


Like that most of my fave diacritics are easily visible and reachable for making smiley faces (yes, that's almost all I'll use them for)


I like that the layout looks pretty sleek and *efficient*.


There are more good points, but I want to compare the others first.

 

[codifies]

Just because you can't think of any doesn't mean there aren't others... Oolite was another one that ptitseb had to fix.

Just because I can't think of any doesn't mean there aren't others... Oolite was another one that ptitseb had to port.

There FTFY...

Software is very much easier to change than hardware thats been forced to cater to dubious corner cases

 

[_wb_]

Just because you can't think of any doesn't mean there aren't others... Oolite was another one that ptitseb had to fix.

Just because I can't think of any doesn't mean there aren't others... Oolite was another one that ptitseb had to port.

There FTFY...

Software is very much easier to change than hardware thats been forced to cater to dubious corner cases

Also, I suppose we could code a "generic compatibility mode" which lets the keyboard behave completely like a standard US-QWERTY IBM-PC keyboard: that is, the Meta keypresses are hidden, and if you press e.g. Meta+Y for {, then it 'fakes' Shift+[ scancodes, etc. That would solve the problem for all lazy ports.

 

[Saber]

In http://www.keyboard-layout-editor.com/#/layouts/8e2043b67cc1b33225d69686868dc76dI think ?_=;: could be moved around and I'm not sure which way I like best.

Maybe this is more or less optimal: http://www.keyboard-layout-editor.com/#/layouts/2cc807dd1656a0703fb8bf12f074357f

Your layouts change hourly. Hard to keep track of them when they aren't concurrently posted in the Final Keyboard Layout Proposals thread which you linked(and where mine is also located BTW).

I dislike where you have underscore, the F11 and F12 pair, and I really don't like that the main modifier on the keyboard is placed on the same side as the primary used symbols : ; - + = / { [ ] }. I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.  

 

[FaeMinx]

What's the easiest way for me to find all the contenders?


Or is that almost impossible until fluctuations have stabilized... There are so many I just didn't bother to look at, assuming there would just be a new one the next day.

 

[Saber]

What's the easiest way for me to find all the contenders?


Or is that almost impossible until fluctuations have stabilized... There are so many I just didn't bother to look at, assuming there would just be a new one the next day.

http://boards.openpandora.org/topic/17568-final-keyboard-layout-proposals//URL]

Though it's not synchronized exactly with this thread. 

 

[codifies]

Your layouts change hourly. Hard to keep track of them when they aren't concurrently posted in the Final Keyboard Layout Proposals thread which you linked(and where mine is also located BTW).

Release early, release often, then reap the benefit of feedback and new ideas.

You can't put down a design then not evolve it or it just becomes dogma much as the DosBox meme that has taken up way more energy than the issue deserves.

I think _wb_ had come up with by far the best compromise with the best clarity, probably because he had modified previous designs on peoples feedback.

 

[_wb_]

In http://www.keyboard-layout-editor.com/#/layouts/8e2043b67cc1b33225d69686868dc76dI think ?_=;: could be moved around and I'm not sure which way I like best.

Maybe this is more or less optimal: http://www.keyboard-layout-editor.com/#/layouts/2cc807dd1656a0703fb8bf12f074357f

Your layouts change hourly. Hard to keep track of them when they aren't concurrently posted in the Final Keyboard Layout Proposals thread which you linked(and where mine is also located BTW).

I dislike where you have underscore, the F11 and F12 pair, and I really don't like that the main modifier on the keyboard is placed on the same side as the primary used symbols : ; - + = / { [ ] }. I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.  

What exactly is it that you dislike about where I have underscore, F11 and F12?

For typing without shoulder buttons, it is indeed slightly more practical to have the modifier on the opposite side from the modified key. That means that in my layout, :;-+=?[]{}\|/ are slightly harder to do, while in your layout, üöäß~`\ F11 F12 and the 3 diacritics are slightly harder to do. In your layout, CapsLock, Esc, = - + _ ' " { } ; : / ? [ ] are on the "easy" side, while in my layout, `~°€ üöäß éèàçñ and the 6 diacritics are on the "easy" side.

I don't have an explicit CapsLock (I think it's not needed), I have a dedicated Esc key elsewhere, and ' " is a dedicated key in my layout.

I think that if you don't use shoulder buttons, then:

• natural language is easier to input on my layout than on your layout: for English it's easier because of the dedicated apostrophe/quote, for German it's easier because üöäß are slightly easier to type, for French and Portuguese it's easier because my layout has a dedicated ç (1 key instead of a 3-key Compose sequence) and dedicated éèà (1 key instead of a 2-key dead diacritic combo), for Spanish it's easier because my layout has a dedicated ñ (instead of a very inefficient 3-key Compose sequence which lets the right thumb travel a lot).
• coding/command line stuff is easier to input on your layout than on mine, provided that you know where to find the symbols you need (they are in pretty non-standard locations in your layout)

 

[comradekingu]

Why is it a compromise at all? Can you explain?

From my point of view its a encumbrance for English users, an impediment for most international users, and flat out scary for new users.

I dont understand the benefit with regard to making it a comprimise.

At some point it makes no sense anymore to use the dead diacritics approach

Since you have diactrics only, that point is right before you get to the most important international/interlingual languages. Unless you ramp up the production of dutch users, that remains the case.

 

[_wb_]

What's the easiest way for me to find all the contenders?


Or is that almost impossible until fluctuations have stabilized... There are so many I just didn't bother to look at, assuming there would just be a new one the next day.

http://boards.openpandora.org/topic/17568-final-keyboard-layout-proposals//URL]

Though it's not synchronized exactly with this thread. 

Synchronized it

Another way to get an overview of the different proposals is by looking at the big comparison table:

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit?usp=sharing

There are links to the different proposals in the second row of that table.

 

[_wb_]

Why is it a compromise at all? Can you explain?

From my point of view its a encumbrance for English users, an impediment for most international users, and flat out scary for new users.

I dont understand the benefit with regard to making it a comprimise.

At some point it makes no sense anymore to use the dead diacritics approach

Since you have diactrics only, that point is right before you get to the most important international/interlingual languages. Unless you ramp up the production of dutch users, that remains the case.

I was talking about obscure dead diacritics like Vietnamese hooks and horns. It does make a lot of sense to have dead acute/grave/circumflex/umlaut, and probably also caron/cedilla/tilde.

When writing a Spanish, you don't want five dedicated keys for áéíóú, you want to have just one dedicated dead acute. Same with the circumflex in French, or the grave in Italian. Don't act as if dead diacritics is just something for Dutch users.

 

[comradekingu]

Thats not what i said though. I said that dead-diactrics only, fails before you consider the most important international/interlingual languages.

The first language you are able to support with only dead-diactrics, is dutch, but that is 4th or 5th down the list, and is covered in smilar fashion anyway.

Dedicated keys reign supreme before then. Im not saying they do the work alone, but without them, you dont have support.

Its a toss-up between dedicated diactrics and hidden AltGr-layer for accentuation, im saying both. However ED says no to printed dedicated diactrics by default. So it can only be where its supposed to be, and hidden.

I am unsure why ED wants 3 modifiers rather than 4, but lets hope its because he doesnt want 4 prints per key. As such, AltGr saves the day, and has no conflict at all with convention or implementing F-keys with Fn.

Even though more obscure languages arent economically viable, it makes sense to include US-style diactrics as a base-level, and an AltGr, because then you cover everything.

 

[Neelix]

I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.

I honestly don't understand why they wouldn't, if the device is held in the hands.  Frankly if people want to make things difficult for themselves by not taking advantage of all the available modifier buttons that's their own lookout.  

Once the device is on a dock or desktop the ergonomics change and having the modifier on the same side of the keyboard is less of an issue.

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

- Neelix

 

[codifies]

I honestly don't understand why they wouldn't,

[use shoulder buttons]  [my addition for clarity]

My hands/fingers are quite long unless the Pyra is quite different in size then it will also be uncomfortable (even painful long term) to use the keyboard AND shoulder buttons at the same time.  You might find them convenient but you can't assume that everyone else without exception would find it desirable or even comfortable...

 

[_wb_]

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

I agree that that's a good way, but I think a better way is to actually label the shoulder buttons and gaming buttons with their functions.

Thats not what i said though. I said that dead-diactrics only, fails before you consider the most important international/interlingual languages.

The first language you are able to support with only dead-diactrics, is dutch, but that is 4th or 5th down the list, and is covered in smilar fashion anyway.

Who is proposing only dead diacritics? I'm not.

But even with only dead diacritics, it's better for German, French, Spanish, Portuguese, Italian and lots of other non-Dutch languages to have dead diacritics than to have nothing at all: éèàüöä in two thumb-presses each (diacritic + letter) is still much better than éèàüöä in three thumb presses (Compose + symbol + letter).

Its a toss-up between dedicated diactrics and hidden AltGr-layer for accentuation, im saying both. However ED says no to printed dedicated diactrics by default. So it can only be where its supposed to be, and hidden.

What do you mean, "ED says no to printed dedicated diacritics"? When and where did he say that?

Even a regular German QWERTZ keyboard has printed dedicated dead acute, grave and circumflex accents, and given that ED seems to want to have all keys of a regular German keyboard labeled (at least üöäߧ°), I would rather expect that he wants to have acute, grave and circumflex.

 

[Neelix]

I agree that that's a good way, but I think a better way is to actually label the shoulder buttons and gaming buttons with their functions.

That too.  I so rarely look at the shoulder buttons on my Pandoras that I tend to forget they are labelled at all though.

What do you mean, "ED says no to printed dedicated diacritics"? When and where did he say that?

As far as I know he didn't.   Someone posted a layout where the majority of the keyboard was covered in dead key diacritics as the alternate symbols, and ED said he didn't like that.  That's not quite the same thing though.

- Neelix

 

[ible]

3. At one point I thought about switching = and +, so there's a symmetry of (-=+). I think it's a net gain for the code-combos score. (It lowers i++, but gains -= and increases /=.) Here's an alternative rearrangement of yours which increases the code combos quite a bit, though it may look a little less symmetric to some:

http://www.keyboard-layout-editor.com/#/layouts/73a832d97d3d555a888dee767649badb

(Nice subtle symmetries: operator opposites are vertically two keys apart.)

 I see your points and I like the subtle symmetries (and the fact that * + / - are in one 'column'), but I prefer to have - and + next to eachother, for programs where they're used for something like zooming in and out or adjusting something. Also maybe for the Compose sequence to produce ±. Minus on the bottom row deviates quite a bit from its expected position.

The symmetry -=+ makes sense in the same way as <=> makes sense. Still I prefer to have -+ and <> as neighbor-pairs.

I understand. I don't mind + on I and - on M, because you can remember it via "Increment" for + and "Minus" for -. You never really need +- together, which is why I put them apart on mine. As for - "too far from normal position", that would be also true of _, which is down by space. In my layout, you keep -_ together.

I like the http://www.keyboard-layout-editor.com/#/layouts/2cc807dd1656a0703fb8bf12f074357f layout, too, but worry that you've lost some of your symmetries (like ; : on the same line). Although you do increase your code combos ..

My biggest problem with

http://www.keyboard-layout-editor.com/#/layouts/1417479de73c9231d7e258fd0eb779a4

is the mix between ASCII punctuation and language-specific precomposed letters. Having them more separated/clustered seems better than having letters like äüößçñ as a Meta key on their 'natural' letter.

It might be better for "hunt and peck" searching for your meta-symbol (because they'll all be in roughly the same area, so you can narrow it down sooner), but putting symbols on their natural letters (or close thereto) makes it easier to remember, giving a quicker-to-memorize layout, perhaps!

 

[Eight Bit]

I like to shamelesly plug my 1st keyboard from a few weeks ago once again.

http://www.keyboard-layout-editor.com/#/layouts/207288cf6cf433f297de3c1ffbb1d1ba

I don't know why CK wrote that dead diacritics are primarely good for dutch as most letters can be made using them. For all the other exotics the compose button is there.

Personaly I will probably never use some of them but that's my language compatibility compromise right there.

It's just 7 dead diacritic keys though, of which I will probably not use 4. In _wb_'s layout for instance which has most combinations written out so to say, I will not use 9 or 10 keys out of the 12(?) available. 

But tbh, if the main concensus is that dedicated characters are preffered, than I guess the diacritics could be replaced by those or maybe _wb_'s keyboard would be the better choice. I guess it's all about whether one likes the diacritics on the left and language ones on the right or the other way around.

In the end it comes down to personal preference I guess.