Explaining keyboard layout proposals. Fn hotkeys updated, language switching, powertoggles etc

[Grench]

Please open a Google Chrome browser and re-read your recent posts. About 1/3 to 1/2 of the Unicode characters show up as a square box. i.e. as uninterpreted.

As I've stated, it is not Pyra games made today that have me cautious on the usage of Unicode (though the Chrome example is pretty wild). It is the that I believe most of the OS ROM engines and game engines used in emulators won't have a clue how to interpret it. Someone who knows more about the emulator/game side of things should step in here. I'm more of a files & audio & office user of the Pandora.

Embedded Number Pad - Do it right or don't bother. I don't see how you can argue that it's 'done' without /*-+.and enter keys. It's a package deal. Having to unlock the number pad, then use shift-key combination to the re-lock the number pad just to add or subtract is silly. I'm sure anyone using the Pyra extensively as an HP or normal calculator or LibreOffice spreadsheet data entry or the like would find it handy - but only if it's got the complete set. Yes, it would be handy to have () and ^ handy too - but then you're getting into algebra and exponential notation which takes a step past data entry and stands on the border of programming - and is outside what a 10-key is normally used for.

 

[slaeshjag]

Emulators that can't handle unicode are broken.

In those cases it needs to display a symbol in a help text or simlar, it can always be worked around. Be it in-line pictures or some other description.

In stuff like ROM pickers, you'll get garbled characters where there's unicode, but it won't break completely. It'll just be more or less an incomprehendable mess for the user, depending on how much of it is unicode.

Assuming the character encoding used in UTF-8, it'll still work. I'll just look weird in broken software.

 

[rygD]

I don't care much how gaming buttons are marked, but I do like the pentagon.  It also got me thinking that maybe we can use pictures representative of old computers and consoles, such as an apple, etc.

 

[Silent-Hunter]

I like just marking them with the unicode page up page down home and end symbols best.

 

[rygD]

That is what makes the most sense to me for functionality.  For fun, I like other options.  For familiarity and the lineage of the Pyra, I think the same markings as on the Pandora will be used.

 

[Silent-Hunter]

I also like the greek symbols.

 

[comradekingu]

I like greek symbols too, not 100% though. Partly its a copycat move, also there is the problem of aping the likeliness of something sony has protection of.

I think for anyone who doesnt like legocolours, a flat black buttoncluster is best. Shouldnt be the hardest thing to stock and apply at build-time as an option.

 

[_jr_]

The major benefit of an embedded numeric keypad (besides fast entry of numbers) is the ability to send the numeric keypad key codes to legacy software that puts important functions on these key codes that can't be (easily) remapped. Therefore every keypad key is important including ENTER. This exact feature was recently requested in the UAE4All thread. IMO this also affects DOS based applications enough to be an issue (even though in a lot of cases remapping is possible, I think it will often result in an even more awkward layout than the embedded keypad).

I can live with any default keyboard label decision made by ED, but I quite like the resent proposals and will probably end up using something very similar to these (F keys on a 12 button row, enter on the bottom right, etc.), so the more closely the default labels resemble these the more happy I'll be. Perhaps we can vote on individual design decisions instead of full layouts? Like the single width space vote? The default binding/label of the new action buttons, the position of modifiers/enter/tab, the position of F keys, the shifted number row are all independent IMO.

 

[Silent-Hunter]

Yes, I forgot about that! There was this DOS game... Q something. Not Qbert I don't think. Anyway, it REQUIRED a numpad.

I also agree, votes on individual design decisions.

EDIT: It didn't start with a Q. It's called Hubie. I love that game.

 

[_wb_]

Please open a Google Chrome browser and re-read your recent posts. About 1/3 to 1/2 of the Unicode characters show up as a square box. i.e. as uninterpreted.

I just did. It shows everything correctly. Of course Unicode is an evolving standard (more and more symbols get added), so you probably are just using old fonts. If we use old Unicode symbols like Greek letters (those were there from the very beginning), they should work correctly everywhere. It may be a good idea to avoid very recent symbols, like the ones that were just added to Unicode 7.0.

I like greek symbols too, not 100% though. Partly its a copycat move, also there is the problem of aping the likeliness of something sony has protection of.

I think for anyone who doesnt like legocolours, a flat black buttoncluster is best. Shouldnt be the hardest thing to stock and apply at build-time as an option.

It's a creative copycat move, like GNU did with Unix if you want -- we take something existing and proprietary, take the good elements out of it, and rebuild it from scratch in a Free and Open way. Of course GNU is Not Unix, and Π Δ Ω χ is not the Sony PlayStation action button layout.

Black unlabeled buttons are a bad idea imo. No way to concisely describe them. Basically we would have 5 or 7 space keys then.

The major benefit of an embedded numeric keypad (besides fast entry of numbers) is the ability to send the numeric keypad key codes to legacy software that puts important functions on these key codes that can't be (easily) remapped. Therefore every keypad key is important including ENTER. This exact feature was recently requested in the UAE4All thread. IMO this also affects DOS based applications enough to be an issue (even though in a lot of cases remapping is possible, I think it will often result in an even more awkward layout than the embedded keypad). I can live with any default keyboard label decision made by ED, but I quite like the resent proposals and will probably end up using something very similar to these (F keys on a 12 button row, enter on the bottom right, etc.), so the more closely the default labels resemble these the more happy I'll be. Perhaps we can vote on individual design decisions instead of full layouts? Like the single width space vote? The default binding/label of the new action buttons, the position of modifiers/enter/tab, the position of F keys, the shifted number row are all independent IMO.

OK, that's a good point. A bit DOS-centric though (what about C64-specific keys etc?).

Can't a DOS emulator be made so that it recognizes some modifier to change the meaning of keys? E.g. if you hold Pyra and Shift while pressing keys from the number row (or Enter or + - / * ), it sends the numpad keycodes instead of the regular ones?

If a DOS game uses the numpad for (8-directional) arrows, you'll want to configure your emulator so that you can use the dpad instead. Having a poor man's dpad on NumLock'ed 789 U O JKL is so awkward that I don't even want to imagine anyone having to do that.

Voting on individual design decisions is a good idea. As long as the combined result of those votes does not turn out to be impossible or suboptimal.

 

[_wb_]

OK, here is a proposal with a full numpad:

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

It has a numpad Enter, +, −, ×, ÷ (I'm using the traditional symbols instead of - * / to emphasize that they're used for math, not for making footnotes and hyphenation etc).

There is a hidden advantage in this layout: it also benefits those who use a language-specific layout that needs P+2 and L+2 for extra letters.

Let me explain.

The L+2 keys are no problem: they have no Pyra-labels, only regular and Shifted, so if you use those keys for extra letters (say Ö and Ä) then you can map the original symbols on those keys (` ~ ' ") to Pyra+[key]. That means you can no longer use the dead key diacritic version of those keys, but that's a fair trade-off: after all, you get your extra letters, and you can still use the alternative dead diacritics (Pyra+: for umlaut, Shift+/ for grave, Shift+\ for acute).

But the P+2 keys are a problem. If you map the -+ key to something else (say Ü), then you need to have - and + somewhere. You can't use Pyra+[key] because that's already used for F11.

Since we now have - and + on NumLock'ed C and V, it becomes an obvious choice to put - and + on Pyra+C/V in that case. Same with Enter: you can do without the keyboard Shift and use it as Enter instead, and it even has the label (although in the default layout, it's numpad enter and only if NumLock is active).

With this I can live. It's killing two birds with one stone (or how do you say it in English? in Dutch we talk about killing two flies in one blow).

 

[WizardStan]

Can't a DOS emulator be made so that it recognizes some modifier to change the meaning of keys?

If a DOS game uses the numpad for (8-directional) arrows, you'll want to configure your emulator so that you can use the dpad instead.

Just this. I don't like the idea of dedicated number pad on the keyboard, it just looks cluttered to me. If you're using it in keyboard mode for entering numbers, you're thumb typing anyway, it doesn't seem like it would make much difference whether you're hitting the enter on the corner or the enter two rows above it. The only time I can think that it would be useful is for games/applications which put specific meaning behind the different keys, where keyboard 5 is different from keypad 5, and in those specific cases it should be possible to change the program to remap the keys more appropriately and note them in the manual: there's no need to add confusion to the keyboard with the symbols.

 

[_wb_]

Can't a DOS emulator be made so that it recognizes some modifier to change the meaning of keys?


If a DOS game uses the numpad for (8-directional) arrows, you'll want to configure your emulator so that you can use the dpad instead.

Just this. I don't like the idea of dedicated number pad on the keyboard, it just looks cluttered to me. If you're using it in keyboard mode for entering numbers, you're thumb typing anyway, it doesn't seem like it would make much difference whether you're hitting the enter on the corner or the enter two rows above it. The only time I can think that it would be useful is for games/applications which put specific meaning behind the different keys, where keyboard 5 is different from keypad 5, and in those specific cases it should be possible to change the program to remap the keys more appropriately and note them in the manual: there's no need to add confusion to the keyboard with the symbols.

I tend to agree. However, that is mostly based on my personal preference. There's a trade-off to be made between visual clutter and functionality here.

I started a poll to get some opinions on this, and on several other design decisions:

http://boards.openpandora.org/topic/16868-the-big-pyra-keyboard-poll//URL]

 

[Grench]

OK, here is a proposal with a full numpad:

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

That numpad is a fail. Position of keys IS important in a number pad. 0 MUST be lower left. . MUST be lower right. Enter must be to the right of 3. + MUST be above Enter. - MUST be above +.

We run out of room for / and *. Those could be just to the left - but the board must still be usable one handed or it misses the point.

Adding keys at random places on the left side of the board is a failure.

Also, the PYRA shifted key symbols on Z and X do not show up in my Chrome browser - only get an orange square. This simply reinforces the dangers of trying to force Unicode on legacy applications. See also every emulator, the ROMs inside the emulators, every legacy game the emulators play, DOS emulators, etc...

 

[slaeshjag]

OK, here is a proposal with a full numpad:

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

Also, the PYRA shifted key symbols on Z and X do not show up in my Chrome browser - only get an orange square. This simply reinforces the dangers of trying to force Unicode on legacy applications. See also every emulator, the ROMs inside the emulators, every legacy game the emulators play, DOS emulators, etc...

That's not a unicode issue. That's just you now having the font installed

 

[moxie]

Please open a Google Chrome browser and re-read your recent posts. About 1/3 to 1/2 of the Unicode characters show up as a square box. i.e. as uninterpreted.

I just want to state that my Chrome is rendering these pages in an absolutely flawless fashion. As does my Firefox. Not that it ought not to, as the problem, as Slaeshjag already said, isn't with the browser but with old fonts.

 

[comradekingu]

Updated firstpost with vote.

 

[Glyph Reader]

Updated firstpost with vote.

Eh, this might be a bit too picky, but that first poll question really bugs me. 

Functional layout vs reduced layout

1. Accomodate as many as possible without making anyone suffer?
2. Accomodate only english people and make everyone else suffer?

It insinuates that accommodating as many people as possible will be suffering-free, which is preposterous.  That kind of layout will be full of compromises on all sides; English will get something not entirely concrete, and international will get something not entirely concrete. I think your bias was showing a bit when you made that. 

I'm probably just nitpicking though. 

-Glyph Reader

 

[comradekingu]

The idea is to accommodate english users as per default, which is the norm.

Then you can switch to the international layout. You then lose the coding input. Which to me is a fair trade, because international users then get something whereas they got nothing before.

English users on the other hand can disregard all of it, and enjoy their coding cluster.

Its what i tried to explain in first-post, and if you disagree, and think it makes english people suffer, that's what the thread is for, so that i understand why.

WB:

• Would it be possible to type F-ing and then go 5 for F5?    Like a dead key-F button, with a little time window that you can type for example F11 in.  F-ing+1+1

It would mean the whole letter are could be letters only.

• I thought of this, since it is already functionally more sound to use ctrl+alt as regular dead-keys, instead of invoking them with meta (something nobody does)

It would mean altGr is the altGr that everyone knows, and F-ing could be exclusivly for hacks.

 

[rygD]

I think I noticed in the other poll that ED picked the option for marking labeling buttons with additional functionality.  Where will these be?  If you can type in F11 and F12 and you can have the labels above the number row it might keep less labels on the keys.

By moving the F keys off the letters it cleans it up for people who want to change the layout to something other than qwerty.