Unofficial keyboard layout poll (bis)

[_wb_]

Now, as far as I know, the number of game devices that actually have both F-keys and shoulder buttons is zero. PC-games may use F-keys, console games may use shoulder buttons, but I don't think there is any type of game that originally uses both the F-keys and the shoulder buttons.

Emulators?  IIRC mednafen on PC uses F keys to enter configuration modes.  Of course anyone who ports an emulator can change that, but with the Pyra being more able to run more powerful emulators without so much optimisation, it will mean that some emulator ports require more work than they otherwise could do.

Perhaps emulator authors could do something simple so they keyboard sticks in Fn-lock mode so that you can use the number row without having to go through the code and modify every keyboard event code.  Or we could go with Kingu's soltution with an F-button key (I disfavour the word 'F-ing' by the way).

Emulators will always need to get modified keymappings compared to the PC version, because no sane emulator author would map the game action buttons to Home/End/PgUp/PgDn by default. So I don't think it's a huge problem to also remap the F-keys to something more convenient.

The point of having useful stuff (like modifiers) on the shoulder buttons is that it's useful; obviously that means that if you're using the shoulder buttons as actual shoulder buttons (like in a game where that makes sense, in particular on emulators that emulate systems which had double shoulder buttons), then you'll have to sacrifice some of that usefulness. We could of course also map the shoulder buttons to numpad 1234, ensuring that there are no clashes whatsoever, but then you lose the convenience of having useful stuff on the shoulder buttons.

The F-keys are mostly used for DOSBox/QEmu stuff, as well as many desktop applications. Luckily, that software expect a normal keyboard (and mouse), not a game controller with shoulder buttons. So it makes perfect sense to have the modifier that is needed to produce F-keys available as a shoulder button.

 

[comradekingu]

No, because then you dont have an AltGr there. No because then you can accidentally Alt+F4.

F-keys are a third rate thing. Nothing produced by the 3 biggest producers have real F-keys in 2015.

The pyra keyboard doesnt have an F-row for a reason. Its the least worthy concern when buttons become an issue.

Meddling together real buttons and concepts just to make it easier to press F-keys doesnt make perfect sense.

0 Avoid clutter to get more sales

1 All letters+numbers

2 Shift symbols In number row

3 AltGr symbols in number row and extra area from 1

4 Ctrl and alt shoulders

5 F-keys/mediabuttons

I dont understand failing application safety/AltGr/mediabuttons just to type F-keys faster.

New users and people with bad eyesight are gone at 0, then half the audience is lost at 1, then every novice user is lost at 3, then pro users are stripped of efficiency.

Who is left to benefit, and why?

 

[_wb_]

No, because then you dont have an AltGr there. No because then you can accidentally Alt+F4.

In my proposal, Meta acts as both F-ing and AltGr, in your terminology, so it is not quite necessary to have an AltGr shoulder button. You can still let one of the Alt keys act as an AltGr in case you need fifth and sixth layers of symbols (in addition to normal, shift, Meta and Shift+Meta), but for most people, AltGr should not be needed if you already have Meta.

Accidentally hit Alt-F4? You mean you accidentally hold down L2 and R2 and then press 4? You know what? I'll take the risk! 'Danger' is my middle name!

 

[comradekingu]

No, in my terminology AltGr does AltGr. Thats what AltGr is.  Its either the one from us international layout, or its the third level modifier. Those are the two options if you dont want to be wrong.

AltGr+A-Z has an expected use already, yours doesnt.

AltGr is supposed to do something + the number buttons. Not primarily all of the keyboard. You cant call that AltGr anymore.

And its called AltGr. In yours it isnt. If you call it meta, it shouldnt have _anything_ to do with AltGr.

Meta, not being AltGr, is meta. To implement extra things, or things you dont have. We need that at the very least for F-keys and mediabuttons. Doing more things the wrong way, is worse.

With keyboards, third level modifier is put on numbers when the "letterspace" isnt there to do so to do so, like the non-english layouts do.

Meta to get shift and AltGr symbols isnt Meta. Its meta.

What if you accidentally F11 because you tried to shift+press something on that button and got the wrong shoulder.  What is a novice to do then, hope for an accidental alt+f4 or a suprise esc-sequence?

Who benefits? Being ok with less isnt a good goal.

 

[_wb_]

No, in my terminology AltGr does AltGr. Thats what AltGr is.  Its either the one from us international layout, or its the third level modifier. Those are the two options if you dont want to be wrong.

Except of course that on normal keyboards, all the keys you have as AltGr keys are not actually AltGr keys: the symbols | @ # ~  % ^ ` = + \ _ / are not AltGr keys on US-International, they're normal primary or shifted keys. The AltGr-numberrow on US-International does ¡ ² ³ ¤ € ¼ ½ ¾ ‘ ’, which is completely different from what your 'AltGr' does with the numberrow.

So this is not a matter of 'right' versus 'wrong'. The Pyra keyboard has too few keys to be a standard full keyboard, so let's not pretend that we can be exactly like a standard keyboard. We can't. At best, we can do something like in B-Zar's proposal and use a low-level Fn key to pretend we have enough keys, but that comes at a heavy price.

Or we can do like in my main proposal, that is, all the standard US-QWERTY keys are available (some of them of course as Meta keys), and if you don't have enough mapping options at the available Meta+letter slots, you are free to map one of the Alt keys (either START or R2) to AltGr, exactly like on a normal keyboard. And that way all AltGr combinations are possible, not just AltGr+letter, but also AltGr+number, AltGr+punctuation, AltGr+F-keys, and so on. The only price to pay is that you either have an efficient shoulder-AltGr, but no longer a regular Alt on a shoulder button (like on the Pandora), or you lose the keyboard Alt. If having two methods for Alt is for some reason extremely important to you (e.g. you use both handheld-mode and tabletop-mode, and you use applications with lots of Alt-shortcuts), then you can still use Super (Pyra logo key) as an extra modifier.

Here is another variant of my proposal, with only one Meta label per key, but unlike this earlier proposal, I kept + and - at the action buttons:

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

 

[comradekingu]

Sure, the ideal would be to have the same number of number-keys. By default it cant be the exact same as any existing layout. Which is not a reason to start inventing entirelly new ways of typing.

On all existing layouts, the useful symbols are on shift+, and secondly, AltGr+  numberrow.

Us layout, as you may well know, also has more letter-keys available, since there are more of those keys too, and that it has a reduced alphabet. Again, not a reason to start inventing things.

Given there is already less keys available, we cant be lazy. Given you cherry-picked your example, it looks as if the alternate side of things doesnt matter. I imply that it does, because everyone who is not using US international layout expects there to be symbols available on the letters with AltGr.

On my keyboard, i can type

Shift+numberrow

§!"#¤%&/()=?`

AltGr+numberrow

¦¡@£$½¥{[]}±´

AltGr+letterkeys

@ł€®þ←↓→œπ

ªßðđŋħł

½«»©“”nµ–

Shift+AltGr+letterkeys

ΩŁ¢™Þ¥↑ıŒΠ

º§ÐªŊĦŁ×

¾<©‘’Nº˛·—

View attachment 11115

These are the reasons why it is more standards-compilant:

1 There are more standard keys

2 Symbols are on numbers.

3 AltGr+ and Shift+AltGr+  is available on all possible keys, see 1

4 Its not a hack

Additional reasons:

AltGr is AltGr

Shift key is shift only

Ins key is Ins only

Del key is Del only

comma and dot are not above each-other.

You have marked the buttoncluster in a activly confusing orientation that is also almost as dead as can be.

Reasons i think doing it one way is preferable:

More efficient typing of comma space, dot space shift, and dot enter.

Space dot and comma is more centrally located.

Less visible clutter.

More languages have full keyboard functionality.

Typing near-key-combos from space gives access to usable things, { } > : you have big A, Z and "

There is a row-of-keys-combo from columnkeys ctrl+alt to 5 6 7, giving most used accentuations.

The additional symbols on numberrow are closer to where some people expect them, even within the row.

Only shift is needed to input natural language.

All brackets are in the same place, none of them are stepped.

Meta is unencumbered apart from F and mediakeys.

More media-keys.

No accidental quitting of programs. Or other unforeseen F- activity.

More closely follows one dead-key per number-key.

Insert and delete (buttoncluster+2) doesnt look like it might be symbols that are just on these buttons instead of fitting on the keyboard.

Shoulder-shift is on the same side as the keyboard, where form follows function

Ctrl shoulder is to the left of alt shoulder like on a real keyboard.

Shift and AltGr follows a pattern where second level modifier is bottom, and top level modifier is top.

Shift AltGr shoulders are in the orientation of a keyboard, left to right. Where form follows placement of print on the key.

Things i dont understand:

Why is there a sysRq key? What can be done when that is a key on the pyra?

When you went with standard US shift+ numbers, why is <> close to where you would find it on ISO keyboards on this?

Reasons i think yours is better:

You have printed F-keys which can be learnt without seeing the desktop wallpaper/conky.

It is easier to type F-keys.

You have a standard shift+numberrow

You have a super.

The reasons i think yours are better are the ones i want to hear about. I am probably missing something. Then we can find out what kind of users stand to benefit from it.

 

[Bosbeetle]

This keyboard disscussion has become such an impenetrable forrest of details I cannot beleive that anybody who hasen't closely followed it will be able to make any suitable vote in this poll. Therefor I will not vote, and hereby advise others in the same boat also not to vote.

 

[_wb_]

This keyboard disscussion has become such an impenetrable forrest of details I cannot beleive that anybody who hasen't closely followed it will be able to make any suitable vote in this poll. Therefor I will not vote, and hereby advise others in the same boat also not to vote.

You don't really have to read the discussion and all of those very impenetrable keyboard threads to vote. Just open all the proposals (links are in the first post), look at them, try to understand them, imagine how you would type a sentence of text on them, imagine how you would use them for other things you do (coding, shortcuts in your favorite desktop applications, etc).  Perhaps ask questions (here or in the layout-specific thread) if something is unclear to you -- this is valuable feedback, though if it's about something important, it's probably a bad points for a proposal if it is unclear. If there's some design decision that strikes you as being particularly weird ("why the hell did you put that key over there?"), then say so -- most likely there's a reason for it, and most likely the proposal author will be glad to explain it to you, so you may want to know that explanation before you vote (or modify your vote afterwards). Just vote based on your personal preferences and priorities.

 

[rygD]

I fully agree.  Vote based on how you imagine the layouts would work for you.  I have been following the keyboard threads but my votes are very different than most of my comments.  I want the keyboard to be useful for people that have different requirements than me, and that will use it differently.  I ignored all that when voting and based it all on what will work best for me in a variety of common scenarios.  That is the only way to get meaningful feedback.

 

[_jr_]

I voted according to the following preferences: as few keys wasted on modifiers as possible, making good use of the keys above the nubs (IMO tab would also fit there nicely), F-keys in a single row, 'DOS-Box-compatability'.

 

[Saber]

Updated my layout again. In my sig, the final keyboard thread, or/and the official thread here. As you were. 

 

[comradekingu]

Agree on modifiers, tab is a good idea, f-keys in a single row is an orthagonal issue, Dos-box compatibility is a matter of supplying a keyconfig with dosbox, which is trivial, it will be done anyhow.

 

[_wb_]

Updated my layout again. In my sig, the final keyboard thread, or/and the official thread here. As you were. 

Nice to see that you're using the layout editor now, that makes it a bit easier to compare the different proposals.


Remark: you shouldn't put shift+AltGr (shouldn't call it AltGr either) things on the number row / F-keys, because you have to be able to do Shift-F-keys. Shift-F5 should be just Shift-F5, not ≥.


Also I wonder how anyone can remember all those shift+AltGr symbols if they aren't labeled. Not that I think that those symbols are very necessary. Most people don't need these symbols: ¡ ¿ § « » ² ³ ≤ ≥ ° ÷ — ¥ µ; if you do for some reason need some of them frequently, you can of course map them somewhere, but I don't think we need them by default. They're also easy to remember with compose:

¡ is ⎄ !!

¿ is ⎄ ??

« is ⎄ <<

» is ⎄ >>

² is ⎄ ^2

³ is ⎄ ^3

≤ is ⎄ <=

≥ is ⎄ >=

° is ⎄ oo

÷ is ⎄ -:

— is ⎄ ---

¥ is ⎄ Y=

µ is ⎄ mu

I would argue that it is easier to remember those default compose combinations (which will work on any Linux system, also on your Pandora for example), than it is to remember their location in your layout. Of course it's a bit more efficient to have a direct key for µ at Shift+AltGr+M than it is to have to type Compose-M-U, but I would say that most people need these symbols so rarely that it doesn't make much of a difference anyway.

 

[Saber]

Updated my layout again. In my sig, the final keyboard thread, or/and the official thread here. As you were. 

Nice to see that you're using the layout editor now, that makes it a bit easier to compare the different proposals.


Remark: you shouldn't put shift+AltGr (shouldn't call it AltGr either) things on the number row / F-keys, because you have to be able to do Shift-F-keys. Shift-F5 should be just Shift-F5, not ≥.


Also I wonder how anyone can remember all those shift+AltGr symbols if they aren't labeled. Not that I think that those symbols are very necessary. Most people don't need these symbols: ¡ ¿ § « » ² ³ ≤ ≥ ° ÷ — ¥ µ; if you do for some reason need some of them frequently, you can of course map them somewhere, but I don't think we need them by default. They're also easy to remember with compose:

¡ is ⎄ !!

¿ is ⎄ ??

« is ⎄ <<

» is ⎄ >>

² is ⎄ ^2

³ is ⎄ ^3

≤ is ⎄ <=

≥ is ⎄ >=

° is ⎄ oo

÷ is ⎄ -:

— is ⎄ ---

¥ is ⎄ Y=

µ is ⎄ mu

I would argue that it is easier to remember those default compose combinations (which will work on any Linux system, also on your Pandora for example), than it is to remember their location in your layout. Of course it's a bit more efficient to have a direct key for µ at Shift+AltGr+M than it is to have to type Compose-M-U, but I would say that most people need these symbols so rarely that it doesn't make much of a difference anyway.

Well, those are very minor nitpicks, and Compose is always available. Are Shift-F-keys that frequently used(even by Pandorians) and without any alternatives? I doubt it. Shift+F10 for pop-up menu I know has one: Right Click. As for the Shift + AltGr symbols, they won't appear on the caps and will be hidden, but I believe recalling where inverted Question Mark and Micro are shouldn't be a problem for most users, unlike say B for the circumflex crowd, which looks nothing like the diacritic, or blank keys which are relatable to nothing. 

Although it was missed, I intentionally placed(look at the number row) these values for remappers who don't want to stir up the AltGr level. Also, many of the symbols in my layout share some observable characteristics with the AltGr value they are occupying the key with, even if you're not familiar with the U.S. International and German AltGr keymaps. Yen and Y are one example as are the superscripts with 2 and 3, interpunct with period, division with plus, underscore and pipe with en/em dashes. A "bonus feature" is I arranged the layout so ' ; [ ] \ ` / all with the help of Shift + AltGr are paired up with their normal shifted values underneath for DOSBox too. 

Now, besides the usual knee-jerk negativity, what do people like about the layout?

 

[ible]

I like how Esc is on Meta+Q, and how +- are above =.

I like discernible patterns (like +- above =, {[]} in a row, '" and ;: next to each other).  But the rest of the symbol positions are a bit strange to me.

 

[Saber]

I like how Esc is on Meta+Q, and how +- are above =.

Other than that, there are very few discernible patterns (+- above =, {[]} in a row, '" and ;: next to each other).  It makes it a little jarring to try and understand the rest of the symbol location choices.

Plus and minus are fine where they are and have always been if your a Pandora owner, very reachable with the thumbs. Equals is closer to the edge like ED wanted rather than on AltGr + g. If you look carefully at my earlier v2 proposal you'll see how we could still put Equal sign on AltGr + s by shuffling a few symbols like ? and ' " around. For the moment, apostrophe, quotes, forward slash, and question are where they were on the Pandora but I do like how they are in v2.

Brackets are in the typical German keyboard pattern: { [ ] }. This could change to { } [ ] though it's okay as a nod to the project leader's homeland. 

Semicolon and Colon, again, are stationed where they were on the Pandora. Many people buying a Pyra will appreciate the familiarity. 

 

[_wb_]

Updated my layout again. In my sig, the final keyboard thread, or/and the official thread here. As you were. 

Nice to see that you're using the layout editor now, that makes it a bit easier to compare the different proposals.


Remark: you shouldn't put shift+AltGr (shouldn't call it AltGr either) things on the number row / F-keys, because you have to be able to do Shift-F-keys. Shift-F5 should be just Shift-F5, not ≥.


Also I wonder how anyone can remember all those shift+AltGr symbols if they aren't labeled. Not that I think that those symbols are very necessary. Most people don't need these symbols: ¡ ¿ § « » ² ³ ≤ ≥ ° ÷ — ¥ µ; if you do for some reason need some of them frequently, you can of course map them somewhere, but I don't think we need them by default. They're also easy to remember with compose:

¡ is ⎄ !!

¿ is ⎄ ??

« is ⎄ <<

» is ⎄ >>

² is ⎄ ^2

³ is ⎄ ^3

≤ is ⎄ <=

≥ is ⎄ >=

° is ⎄ oo

÷ is ⎄ -:

— is ⎄ ---

¥ is ⎄ Y=

µ is ⎄ mu

I would argue that it is easier to remember those default compose combinations (which will work on any Linux system, also on your Pandora for example), than it is to remember their location in your layout. Of course it's a bit more efficient to have a direct key for µ at Shift+AltGr+M than it is to have to type Compose-M-U, but I would say that most people need these symbols so rarely that it doesn't make much of a difference anyway.

Well, those are very minor nitpicks, and Compose is always available. Are Shift-F-keys that frequently used(even by Pandorians) and without any alternatives? I doubt it. Shift+F10 for browser refresh I know has one: Right Click. As for the Shift + AltGr symbols, they won't appear on the caps and will be hidden, but I believe recalling where inverted Question Mark and Micro are shouldn't be a problem for most users, unlike say B for the circumflex crowd, which looks nothing like the diacritic, or blank keys which are relatable to nothing. 

Although it was missed, I intentionally placed(look at the number row) these values for remappers who don't want to stir up the AltGr level. Also, many of the symbols in my layout share some observable characteristics with the AltGr value they are occupying the key with, even if you're not familiar with the U.S. International and German AltGr keymaps. Yen and Y are one example as are the superscripts with 2 and 3, interpunct with period, division with plus, underscore and pipe with en/em dashes. A "bonus feature" is I arranged the layout so ' ; [ ] \ ` / all with the help of Shift + AltGr are paired up with their normal shifted values underneath for DOSBox too. 

Now, besides the usual knee-jerk negativity, what do people like about the layout?

I'm trying to give constructive feedback, not knee-jerk negativity

Shifted F-keys (and Ctrl-Shift F-keys) are something you really should not dismiss that easily. It is very weird to me that a keyboard would have F-keys, but does not allow you to do Shift + F-keys. Yes, of course Meta+Shift+6 would be a nice location for a dead circumflex, but that breaks Shift-F6 so it's not a good idea. Also note that in my proposal, Meta+B for dead circumflex is actually labeled, so you don't need to remember it (circumflex does indeed have nothing to do with the letter B, mnemonically).

Anyway, I can ignore the labels that are not printed: if I don't like them, I can change what they do anyway.

The labels that are printed, then:

• It's nice that your layout is relatively close to the Pandora layout. I don't think it matters that much though -- there are not that many Pandora users out there, and the 'feel' will be different anyway, with the extra keys and the standard Shift+number row. I think it's fine to deviate more from the Pandora layout (in ways that make sense, of course) without upsetting Pandora users.
• I don't need äöüß, so to me (personally) it's just ugly German stuff on my keyboard. I can imagine that Germans have less of a problem with this. Still, I don't think most Germans have a big problem with äöüß unlabeled, but in a logical position, like Meta+AOUS in my proposal.
• {[]} is a nice onion-like stack, but when coding I usually immediately type both the opening and the closing brackets, e.g. () or {}, and then move the cursor in between if needed. So I like it better when { and } are neighbors
• You have dead grave, dead acute and dead circumflex (though the dead circumflex is in an impossible position). You don't have dead umlaut. And no, the äöü don't cover it: the umlauts I need most frequently are ë and ï.
• Where would you suggest people map ç and ñ?
• Three shift keys and four alt keys looks a bit excessive for a keyboard that is short on keys.
• It is confusing that the labels + and - are on the action buttons while those keys do not actually produce the symbols + and -
• Same with ABXY. I guess nobody will expect them to output the letters ABXY, but keep in mind that they will probably look more like the other keys (they'll probably also be backlit and be made out of the same material as the rest of the keyboard?), so the confusion could increase compared to the Pandora. "Press A to abort", if that statement is followed by "or press B to continue", then it's probably the action button (A); if it is followed by "or press C to continue" then it's probably the letter key A.
• Direct primary toggle keys for BT and Wifi, is that a good idea? What if you accidentally hit them? And if you have a confirmation dialog, why not stick to just one 'hardware' button that lets you toggle all kinds of hardware? (e.g. what about gps? hdmi? some other setting we forgot about?)

 

[ible]

This is the bad thing about a few unofficial keyboard polls...

I count a few people from my one who haven't chimed in on this one (Askarus, ouroboros, Zink, who all voted for Saber's layout; Inqui, Wilhelm, and nomax for _wb_'s).

 

[levi]

Is that a bad thing?  Why?

 

[Saber]

Updated my layout again. In my sig, the final keyboard thread, or/and the official thread here. As you were. 

Nice to see that you're using the layout editor now, that makes it a bit easier to compare the different proposals.


Remark: you shouldn't put shift+AltGr (shouldn't call it AltGr either) things on the number row / F-keys, because you have to be able to do Shift-F-keys. Shift-F5 should be just Shift-F5, not ≥.


Also I wonder how anyone can remember all those shift+AltGr symbols if they aren't labeled. Not that I think that those symbols are very necessary. Most people don't need these symbols: ¡ ¿ § « » ² ³ ≤ ≥ ° ÷ — ¥ µ; if you do for some reason need some of them frequently, you can of course map them somewhere, but I don't think we need them by default. They're also easy to remember with compose:

¡ is ⎄ !!

¿ is ⎄ ??

« is ⎄ <<

» is ⎄ >>

² is ⎄ ^2

³ is ⎄ ^3

≤ is ⎄ <=

≥ is ⎄ >=

° is ⎄ oo

÷ is ⎄ -:

— is ⎄ ---

¥ is ⎄ Y=

µ is ⎄ mu

I would argue that it is easier to remember those default compose combinations (which will work on any Linux system, also on your Pandora for example), than it is to remember their location in your layout. Of course it's a bit more efficient to have a direct key for µ at Shift+AltGr+M than it is to have to type Compose-M-U, but I would say that most people need these symbols so rarely that it doesn't make much of a difference anyway.

Well, those are very minor nitpicks, and Compose is always available. Are Shift-F-keys that frequently used(even by Pandorians) and without any alternatives? I doubt it. Shift+F10 for browser refresh I know has one: Right Click. As for the Shift + AltGr symbols, they won't appear on the caps and will be hidden, but I believe recalling where inverted Question Mark and Micro are shouldn't be a problem for most users, unlike say B for the circumflex crowd, which looks nothing like the diacritic, or blank keys which are relatable to nothing. 

Although it was missed, I intentionally placed(look at the number row) these values for remappers who don't want to stir up the AltGr level. Also, many of the symbols in my layout share some observable characteristics with the AltGr value they are occupying the key with, even if you're not familiar with the U.S. International and German AltGr keymaps. Yen and Y are one example as are the superscripts with 2 and 3, interpunct with period, division with plus, underscore and pipe with en/em dashes. A "bonus feature" is I arranged the layout so ' ; [ ] \ ` / all with the help of Shift + AltGr are paired up with their normal shifted values underneath for DOSBox too. 

Now, besides the usual knee-jerk negativity, what do people like about the layout?

I'm trying to give constructive feedback, not knee-jerk negativity

Shifted F-keys (and Ctrl-Shift F-keys) are something you really should not dismiss that easily. It is very weird to me that a keyboard would have F-keys, but does not allow you to do Shift + F-keys. Yes, of course Meta+Shift+6 would be a nice location for a dead circumflex, but that breaks Shift-F6 so it's not a good idea. Also note that in my proposal, Meta+B for dead circumflex is actually labeled, so you don't need to remember it (circumflex does indeed have nothing to do with the letter B, mnemonically).

Anyway, I can ignore the labels that are not printed: if I don't like them, I can change what they do anyway.

The labels that are printed, then:

• It's nice that your layout is relatively close to the Pandora layout. I don't think it matters that much though -- there are not that many Pandora users out there, and the 'feel' will be different anyway, with the extra keys and the standard Shift+number row. I think it's fine to deviate more from the Pandora layout (in ways that make sense, of course) without upsetting Pandora users.
• I don't need äöüß, so to me (personally) it's just ugly German stuff on my keyboard. I can imagine that Germans have less of a problem with this. Still, I don't think most Germans have a big problem with äöüß unlabeled, but in a logical position, like Meta+AOUS in my proposal.
• {[]} is a nice onion-like stack, but when coding I usually immediately type both the opening and the closing brackets, e.g. () or {}, and then move the cursor in between if needed. So I like it better when { and } are neighbors
• You have dead grave, dead acute and dead circumflex (though the dead circumflex is in an impossible position). You don't have dead umlaut. And no, the äöü don't cover it: the umlauts I need most frequently are ë and ï.
• Where would you suggest people map ç and ñ?
• Three shift keys and four alt keys looks a bit excessive for a keyboard that is short on keys.
• It is confusing that the labels + and - are on the action buttons while those keys do not actually produce the symbols + and -
• Same with ABXY. I guess nobody will expect them to output the letters ABXY, but keep in mind that they will probably look more like the other keys (they'll probably also be backlit and be made out of the same material as the rest of the keyboard?), so the confusion could increase compared to the Pandora. "Press A to abort", if that statement is followed by "or press B to continue", then it's probably the action button (A); if it is followed by "or press C to continue" then it's probably the letter key A.
• Direct primary toggle keys for BT and Wifi, is that a good idea? What if you accidentally hit them? And if you have a confirmation dialog, why not stick to just one 'hardware' button that lets you toggle all kinds of hardware? (e.g. what about gps? hdmi? some other setting we forgot about?)

Now your reaching, and your use-case is on the more extreme end compared to the average user if you hadn't noticed. Besides, I happen to be German so the umlauts and { [ ] }, which could still change ordering to { } [ ], are welcoming. 

For your situation, as a start with the rest to figure out on your own, remap over the German umlauts you don't need for Circumflex. It won't cover all of them but that takes care of four of them(or you could change Dead Grave or Acute to Dead Circumflex, depending on which group has a greater number of diacritics needed). Dead key diacritic for umlauts, additionally, could be on Shift + AltGr + s and Shift + AltGr + n or m for Circumflex. There's also Shift + AltGr + Euro if you find Scroll Lock unnecessary.

Letters ç or ñ could go over Euro and the other you'll make with Compose, or place it and any others under Shift + AltGr, mapping over those, like en and em dash which you don't need. Shift + AltGr, as it concerns the F-keys, has a simple solution: we don't put any values there, that is, if people(more than solely you) require Shift + F1-12 shortcuts. You didn't answer me yet but are there alternatives to those Shift F-key shortcuts?

As you said, + and - will be no more confusing than ABXY. The individual will have a Eureka moment when they look at the keyboard anyways and notice - and + with their brethren. Better than having + and - so far away from them, eh?

Concerning BT and WiFi, you did notice their location way, way up top? How does one accidently hit those keys? As for GPS and HDMI, there are AltGr + top key slots vacant.