Ayep. I think a Good Thing would be to include a simple-to-use keyboard remapping tool in the basic OS, and a keymap switcher/viewer widget. To have both a simple way to see where an uncommon glyph is mapped, and a simple way to customise the mapping for different use cases or languages (I'd probably have one "programming" keymap and one "writing" keymap, and switch when necessary).
This was proposed for the original Pandora keyboard as well. The counter argument was that for the infrequently used keys that would go on them it would be hard to remember what each one was without a label. I'm not sure if I agree with that or not.
Yes. I'm asking for a "second shift" if that makes more sense to you. Using a compose key might not seem like a big deal, but try writing "Äänekäs känni-ääliö häiriköi hääyön päämäärään kävelyä" (translation: "The loud drunken idiot distracted the walk to wedding night's destination") using those.
I know what B-zar was asking and I disagreed with him that we need another modifier key added to what we already have available. I did want his opinion on what could be put on the row I mentioned. From that prototype(or whatever) board, I'm basing my layout on it as I don't see where extra keys would fit on a 1-2mm expanded lengthwise Pandor-ish handheld. Not between the center nor the sides without severe compromises to the physical key sizes.The main problem is that people are discussing different things, and then mistakes arguments in one part of the thread to be about another part. There are at least two main strains of this thread:
* What number of keys ought the keyboard to have, and in what configuration. That is, keytops.
* What characters are important enough to be printed on the keytops, and in what positions and colours.
These are two very different things, and when these are confused, as for instance when Slaeshjag remarked that he wanted keys between P and Enter (keytops) and got criticized for wanting to print strange swedish characters there (which he said nothing about), things get confused. And when people get confused they raise their voices, and everything gets progressively worse. Relax, breathe and read again is, I think, a good advice for many
This is typical for such a confusion. B-zar isn't asking for specific diacritics or characters, he is asking for good access to modifier keys so that we can offset the smaller number of keytops. Different thing, irrelevant followup question.
I don't believe the physical number of keys in the layout will change from the video ED posted. No need to as I've illustrated.
I'd like that to happen as an alternative to others of course.
I Agree.
As I've said above, we already have a plentiful amount of options handy. Shift-Enter and a remap app should suffice. Too bad custom keymats can't be made this time around(or could they?).Yes. I'm asking for a "second shift" if that makes more sense to you. Using a compose key might not seem like a big deal, but try writing "Äänekäs känni-ääliö häiriköi hääyön päämäärään kävelyä" (translation: "The loud drunken idiot distracted the walk to wedding night's destination") using those.
shift-enter fn-s shift-a shift-enter fn-s a n e k shift-enter fn-s a s k shift-enter fn-s a n n i - shift-enter fn-s a shift-enter fn-s a li shift-enter fn-s o h shift-enter fn-s a i r i k shift-enter fn-s o i h shift-enter fn-s a shift-enter fn-s a y shift-enter fn-s o n p shift-enter fn-s a shift-enter fn-s a m shift-enter fn-s a r shift-enter fn-s a shift-enter fn-s a n k shift-enter fn-s a vely shift-enter fn-s a.
Compose key may be a solution for a few odd accents, but especially ä is surprisingly common letter in finnish. According to wikipedia, ä is about as common in finnish as c or f is in english.
Now, I'm not saying any specific non-english layout should be pandered to. By having an unmapped shift-type key in the layout the users can map all their non-ascii stuff behind it. Everyone wins
Your mockup will make the keys super tiny. We're talking Blackberry territory and those keys in the second picture crowded into the center will likely be difficult to press individually. :mellow:Here is a variant of the layout I proposed above:
http://www.keyboard-layout-editor.com/#/layouts/ac06aceb440f999ce85a899eacae85c6
Here's a mockup of how my ideal Pyra would look like:
(except with the status leds somewhere else, either in the hinge like on the Pandora, or in the front)
Seems to be the unanswerable question but I'll try here. What keys do you need that are cumbersome under Compose that might show up on the Tab-/ with Fn row? Thoughts?
Would the keys really be that much smaller, provided the device is slightly wider (maybe 0.5 or 1cm) and the spacing between the keys would be reduced a tiny bit? On the current Pandora, there are 11/10/11/12 keys per row, but you can easily imagine 12/12/11/12 keys per row. My proposal has 15/15/14/15 keys per row, which means the keys would need to take 20% less horizontal space than they do now, if you keep the total width and spacing identical.Your mockup will make the keys super tiny. We're talking Blackberry territory and those keys in the second picture crowded into the center will likely be difficult to press individually. :mellow:Here is a variant of the layout I proposed above:
http://www.keyboard-layout-editor.com/#/layouts/ac06aceb440f999ce85a899eacae85c6
Here's a mockup of how my ideal Pyra would look like:
(except with the status leds somewhere else, either in the hinge like on the Pandora, or in the front)
My impression is the Pyra will be 1-2mm longer than it's precursor. That's not much room for adding two columns of keys to an already mildly awkward spot(I found Start and Select weren't the most reachable keys to press). Reducing them to tic-tac dimensions adds to the nuisance.Here is a variant of the layout I proposed above:
http://www.keyboard-layout-editor.com/#/layouts/ac06aceb440f999ce85a899eacae85c6
Here's a mockup of how my ideal Pyra would look like:
(except with the status leds somewhere else, either in the hinge like on the Pandora, or in the front)
Your mockup will make the keys super tiny. We're talking Blackberry territory and those keys in the second picture crowded into the center will likely be difficult to press individually. :mellow:
Would the keys really be that much smaller, provided the device is slightly wider (maybe 0.5 or 1cm) and the spacing between the keys would be reduced a tiny bit? On the current Pandora, there are 11/10/11/12 keys per row, but you can easily imagine 12/12/11/12 keys per row. My proposal has 15/15/14/15 keys per row, which means the keys would need to take 20% less horizontal space than they do now, if you keep the total width and spacing identical.
That is very close to ideal. I particularly like the black letters on whitish keys. The user configurable color LED backlighting should look very cool coming up through those translucent key tops. The central 12 key pad needs to be made whitish - and same with the game controller pads. Everything but the nubs themselves should glow under backlight - and those should have glowing circles around them.Here is a variant of the layout I proposed above:
http://www.keyboard-layout-editor.com/#/layouts/ac06aceb440f999ce85a899eacae85c6
Here's a mockup of how my ideal Pyra would look like:
(except with the status leds somewhere else, either in the hinge like on the Pandora, or in the front)
Thanks.
/me thinks the space-bar should be al least twice as wide as other keys.
Crimson or Chrome. Lovely.Here is a variant of the layout I proposed above:
http://www.keyboard-layout-editor.com/#/layouts/ac06aceb440f999ce85a899eacae85c6
Here's a mockup of how my ideal Pyra would look like:
(except with the status leds somewhere else, either in the hinge like on the Pandora, or in the front)
While we're talking color - I loved the red case that was used in that animation. I didn't think I'd like colored cases - but that one looks awesome. Red case. White keys that can color shift on whatever the user sets the LED back lighting to. Black nubs. Using red backlighting - that would look quite evil indeed.
