It's the keyboard layout.

[Saber]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

 

[ible]

I agree we have gone far afield of the original Saber layout which started this thread.

In homage, here's an ible version

http://www.keyboard-layout-editor.com/#/layouts/30f97f61547c4f6510370d927ff1a82a

 

[Grench]

Its a shame a very vocal minority will slap this down so they can run some 30+ year old software conveniently....

[sarcasm]Good point! Nobody would ever want to run 30 year old software on the Pyra. Let's completely ditch any capability to run any emulators. We could then put in a proprietary app store with DRM protection so that the application they purchase can be coded to only be run on the one device that they downloaded it to. Oh, and that Exagear/QEMU thing that is opening up a completely new category of games, but is effected the same way as DosBox? Nobody should be allowed to have the layout match with that either. Let's all dance around a bonfire chanting that we want less compatibility and lowered capabilities![/sarcasm]

The Pyra is a multi-function computing device with game controls. The Pandora was built for old console emulation, but turned out to get used as a multi-function computer too. The Pyra, being much more powerful than the Pandora, will have additional software thrown at it. Yes, this includes X86 games (DOS, Linux and yes some Windows games). That capability is there in the rest of the hardware. Why on Earth would you want to cripple that experience/capability/feature?

 

[szr]

Like this? http://www.keyboard-layout-editor.com/#/layouts/b27512781b9633d89b088d83f3648b6f

Yes this looks good. One question, even though pairs (at least how they are on a US keyboard) are separated, would pressing, for example, Shift + ; still produce a : or Shift + [ yield a {   ?

 

[Grench]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

So you're against the compromise layouts where we actually incorporate other's needs?
We have all learned a lot in this exercise. You're assuming EvilDragon is omniscient and already knew and stated everything that needed to be known. I argue that he wanted to give us a place to start and see where it took us. Unfortunately, it became very clear that his post had requirements that could not be serviced by the layout that he picked as his original favorite.

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.

http://en.wikipedia.org/wiki/Compromise

To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.

Compromise can be a great thing. The layouts that grew through compromise have all of the needs and most of the wants from within the community. They excel in compatibility with legacy software (DosBox & QEMU), support many languages, don't confuse AltGr as anything other than the right Alt, have logical layouts with keys near their 'normal' locations, etc...

These have HIGH functionality with very few negative compromises.

These are light years ahead of any layout that had been created prior to EvilDragon opening this thread.

These were built through compromise and collaboration.

These incorporate more user's needs and wants while remaining relatively uncluttered and simple to use.

These have all key functions neatly labeled in such a way that they should work under ANY environment.

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

http://www.keyboard-layout-editor.com/#/layouts/866783c8daef0faba6a2ff194bc3492f

So, are you sure you're not using the negative definition of "compromise"?

In the negative connotation, compromise may be referred to as capitulation, referring to a "surrender" of objectives, principles, or material, in the process of negotiating an agreement.

 

[Saber]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

So you're against the compromise layouts where we actually incorporate other's needs?

We have all learned a lot in this exercise. You're assuming EvilDragon is omniscient and already knew and stated everything that needed to be known. I argue that he wanted to give us a place to start and see where it took us. Unfortunately, it became very clear that his post had requirements that could not be serviced by the layout that he picked as his original favorite.

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.

http://en.wikipedia.org/wiki/Compromise

To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.

Compromise can be a great thing. The layouts that grew through compromise have all of the needs and most of the wants from within the community. They excel in compatibility with legacy software (DosBox & QEMU), support many languages, don't confuse AltGr as anything other than the right Alt, have logical layouts with keys near their 'normal' locations, etc...


These have HIGH functionality with very few negative compromises.


These are light years ahead of any layout that had been created prior to EvilDragon opening this thread.


These were built through compromise and collaboration.


These incorporate more user's needs and wants while remaining relatively uncluttered and simple to use.


These have all key functions neatly labeled in such a way that they should work under ANY environment.

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

http://www.keyboard-layout-editor.com/#/layouts/866783c8daef0faba6a2ff194bc3492f


So, are you sure you're not using the negative definition of "compromise"?

In the negative connotation, compromise may be referred to as capitulation, referring to a "surrender" of objectives, principles, or material, in the process of negotiating an agreement.

Calm down.

I'm taking what ED said as what ED wants which carries significant weight since he is the guy making the device and is whom we will be buying it from.  

 

[Eight Bit]

Small alteration;

http://www.keyboard-layout-editor.com/#/layouts/7d594f4fe279b94435d9874fe4916f42

turtle coming through!

btw, Though a good idea, I think the comparison sheet fluked as just keyboard creators voted in it. By no means it is a viable representation of the to-be user base like this. At the very least a couple 100 people need to vote in it for it to be a decent representation imo.

 

[_wb_]

Small alteration;

http://www.keyboard-layout-editor.com/#/layouts/7d594f4fe279b94435d9874fe4916f42

turtle coming through!

btw, Though a good idea, I think the comparison sheet fluked as just keyboard creators voted in it. By no means it is a viable representation of the to-be user base like this. At the very least a couple 100 people need to vote in it for it to be a decent representation imo.

What keycodes do those three Shift keys, three Alt keys and three Meta keys produce? And why do you have only two Ctrl keys? I want at least 5 of them!!11!!11!

 

[codifies]

[sarcasm] Sarcasm tags really prevent you from giving people the idea that you have a poor attitude [/sarcasm]

I wish when I got hold of a Pandora for the first time that my keyboard skills instantaneously transfered to using just two thumbs on tiny keys, unlike the instantly skilled I had a few days of looking down at the (fortunately) clearly labelled keys, before I was able to thumb touch type as its quite a different skill to using a full sized keyboard which did NOT transfer

Of all the retro platforms to emulate the PC DOS era is by FAR the poorest - the games of the time that used DOS and keyboard only were basically pants compared with their console counterparts, with the exception of some text adventures (were keycodes are less of an issue and better emulated on other platforms (z-machine is everywhere!) )

Later when games became better on PC they were much more configurable (joystick or actual choice of keys :-o ) which makes a rigid keymap less needed

Why wreck a keyboard that could be great for coding, email, letters, browsing, etc etc Just for one retro corner case that's just not worth it ...

 

[Eight Bit]

The shoulder buttons could just be a copy of either left or right meta and Shift. You might think it's too much but I think it'll be awesome having meta or fn or whatever on both sides of the keyboard as well as on the shoulders. Try pressing F11 on the Pandora for instance. it's ackward and uncomfortable.


But anyway, constructive criticism is always welcome so if you (or any one else) has a great idea to improve on this, pls let me know.

 

[comradekingu]

So if we divide all users into first English and International

The English users dont want foreign symbols, ED doesnt want dedicated diactrics symbols. International users want/need dedicated keys, but we cant give up any buttons for it. Because the keyboard doesnt have any extra buttons to spare.

Usecases, Writing, playing games, using the OS, coding (more?)

Writing letters is covered by the above compromise. The most used arrangement of symbols is the US shift-row, that can be combined with US-international diactrics so that you avoid
EDs gripe above and still can input all different things.

Some users are even interlingual, so to deal with this, the interlingual letters can be on the hidden AltGr layer, again respecting english users wish not to have foreign letters visible.
That works well, with German, Spanish and italian, but is not yet solved for French. The symbols from the non-A-Z keys that cant be given up, are also duplicated on this layer, so users are
free to put in their language-modifiers or dedicated letters.

Before we dvelve deeper, do we all agree to give this much so that no big group is excluded?

From my understanding ED wants "all users" and doesnt want to scare away "new prospective buyers" if i remember it verbatim.

Those are good points, I think we should also cater to the very lowest denominator. This is compatible with sleekness.

Are there any special things that need to be implemented that are so good that new/novice users cant use a pyra?

 

[_wb_]

Like this? http://www.keyboard-layout-editor.com/#/layouts/b27512781b9633d89b088d83f3648b6f

Yes this looks good. One question, even though pairs (at least how they are on a US keyboard) are separated, would pressing, for example, Shift + ; still produce a : or Shift + [ yield a {   ?

That could be done. But why?

If qemu/dosbox is the main reason for wanting to have : { } etc at Shift+ ; [ ] etc, then the best solution is to adapt/configure qemu/dosbox so that it provides better emulation for an IBM-PC keyboard on the Pyra keyboard. Just like a C64 or Amiga or whatever emulator needs to be adapted or configured to emulate the C64 or Amiga keyboard on the Pyra keyboard. We shouldn't let legacy devices dictate how we layout the keyboard.

I still don't have strong feelings w.r.t. the main design choice we are left with (besides comradekingu's stuff): do we use Meta+Shift for {}:_+?~ etc, or do we map everything to just Meta?

There are reasons for both:

• Using Meta+Shift means less keys are needed to map the 9 "missing" symbol keys -=[]\;'/`  and their Shifted values _+{}|:"?~, so they can be mapped closer to their normal position, and more keys are available to do other things like non-ASCII symbols / international support. Possibly some applications will work better or require less configuration/bugfixing if they assume standard symbol shift-symbol pairs.
• Using Meta only means all symbols can be inputed using only one modifier (reducing potential chording issues), and two labels per key are possible which means bigger font sizes can be used. There is still room left for e.g. àèéç ñ üöäß € °, and many people seem not to want language-specific precomposed letters labeled on their keymat anyway, so why would everything be cramped onto just a few keys? Keeping all the letter keys free of Meta-labels is impossible anyway (unless you go the comradekingu route and apply tricks like an extra modifier for F-keys and wobbly space effects).

 

[codifies]

The English users dont want foreign symbols,

I'm a UK user and I DO want diacritics but I don't want them to crowd making the keyboard difficult to learn (and they don't need to)

I wouldn't be so ignorant to demand that the keyboard only catered to English - its an international device isn't it?

 

[Saber]

Version 3.0.

• Removed the DOSBox compatibility layer symbol set from my 2.1 layout(though they are still attendant here).
• Added three of the most important dead key diacritics as I see it on Fn + u, n, and m. Shown underlined as they may be on the actual keycaps(like here) they are Dead Circumflex, Dead Grave, and Dead Acute but could as always be remapped by the user into something else. Ä, Ö, Ü, and ß are also user remappable if desired.
• Changed one of the keyboard Shift keys back to Right Shift until it's proved advisable not to have it there.

 

[Grench]

The English users dont want foreign symbols,

 I'm a UK user and I DO want diacritics but I don't want them to crowd making the keyboard difficult to learn (and they don't need to)

I wouldn't be so ignorant to demand that the keyboard only catered to English - its an international device isn't it?

I'm a US English only (OK, some minor Spanish use), but I don't mind giving a nod on the Fn layer to the added support needed to create the characters in more languages.

That is why I like this compromise solution:

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

English use is very clear and easy to find.

The non-English keys are on the left 2/3 of the Fn layer where I don't have to be concerned by them.

The primary diacritics are paired to their base key sets. Easy to get to them if you want them, easy to ignore if you don't.

All key pairs are retained. DosBox should be happy.

All of the symbols are either on the top layer (most commonly used ones are) or near their normal US locations on the Fn layer.

Symbols !@#$%^&*()`~'",<.>[];\-= are all 24 available with either no or a single modifier (none or Fn or Shift) key.

Symbols |_+{} are the only 7 requiring chording Fn+Shift.

 

[_wb_]

This is the best I can come up with for a Shift+Meta layout:

http://www.keyboard-layout-editor.com/#/layouts/1fd0daf5797efa87c0c0436cbe676b38

It covers English, German, French, Spanish, Portuguese*, Italian**, Scandinavian languages, most Balto-Slavic*** languages

* if tilde is made a dead key so you can type ãõ

** if grave is made a dead key so you can type ìò

*** not very efficiently; you would need to use dead caron, ogonek, etc a lot

(You could of course drop support for some or all of those languages and simplify the labeling, but why have a backlit keyboard and make room for extra symbols by squeezing \|-_=+[{]};:/? together, if all the extra room goes unused and people have to remap&remember anyway?)

This is the best I can come up with for a Meta-only layout:

http://www.keyboard-layout-editor.com/#/layouts/12a133ea8ca2ae5ffc9d9a341f094d48

It covers English, German, French, Spanish*, Portuguese, Italian.

* without the ¡¿ labeled; Shift+? is available for ¿

 

[codifies]

Out of the two I think http://www.keyboard-layout-editor.com/#/layouts/12a133ea8ca2ae5ffc9d9a341f094d48looks easier to use...

 

[_wb_]

Out of the two I think http://www.keyboard-layout-editor.com/#/layouts/12a133ea8ca2ae5ffc9d9a341f094d48looks easier to use...

I am also personally slightly in favor of Meta-only, 2-labels-per-key.

It looks more as if it was meant to be like that, instead of having something that tries to imitate a full keyboard but just lacks keys. E.g. the pattern { } \ | / [ ] looks rather pleasing to me, and the - + = with / * ( ) nearby too. Also, | (or) below & (and), / (division) below * (multiplication), and the punctuation symbols ? : ; , . in a nice arc around space (these symbols are almost always followed by space, so you get some nice button-mash combos there). It looks clean.

Of course you can reverse that argument and say that the layout with Shift+Meta is closer to a standard full keyboard. That's mostly only true w.r.t. the symbol shift-symbol pairings, not really w.r.t. the symbol locations: in both of these proposals, the symbols are roughly near their 'normal' position, but not at their normal position (we would need at least two more keys on every row for that) or even at a consistent offset from their normal position (e.g. all on the correct row and 3 positions more to the left than normal).

So given that a full keyboard layout is impossible anyway (not enough keys), it makes sense to follow US-QWERTY for the keys we have (letters, numbers, two or three punctuation symbols), while doing something that makes more sense for the 'missing' keys. In particular, -_ and =+ are weird pairs in US-QWERTY, making - = primary symbols and _+ shift symbols. Having + and - on the same level makes much more sense, and underscore doesn't really belong there at all: underscore is not used in arithmetic, unlike * ( ) - = +. Also three out of four basic arithmetic operators * - + are on that top row, while division / is quite far away. Minus and division are primary symbols (of course that's because they are also dash and slash), while the more important plus and multiplication are shift symbols. And so on.

We just have to make sure that DOSBox etc are properly ported/configured such that if you press ':' on the Pyra, then it produces a ':' in the emulated DOS. This can be done.

 

[Neelix]

Out of the two I think http://www.keyboard-layout-editor.com/#/layouts/12a133ea8ca2ae5ffc9d9a341f094d48looks easier to use...

...except it has compose and _ both on meta+space.  :lol:

In any case I'm still in favour of the meta+shift version myself.

If I might suggest an adjustment to that meta+shift layout  I'd suggest taking a cue from the US-International layout and placing ß and § on meta+S and meta+shift+S respectively.    That would free up meta+T for something else.  (eg œ)

- Neelix

 

[codifies]

We just have to make sure that DOSBox etc are properly ported/configured such that if you press ':' on the Pyra, then it produces a ':' in the emulated DOS. This can be done.

heretic! burn the blasphemer !

I was beginning to think I was the only one to think that one piece of software should be fixed, instead of bodging hardware to work with it and making every other user/piece of software suffer...