It's the keyboard layout.

[Eight Bit]

Isn't there too much focus on multi language support?

Here I come barging in again with another lay-out.

This time, again Pandora compatible but with Standard US shift pairs on the Fn layer and broad diacritic support.

 

[comradekingu]

I think æøå are missing. And i would never buy that if i could get its other qualities elsewhere.  If i had it i would probably try to use it socially, get annoyed, put it away.


Writing o for ø in Norwegian is about as socially acceptable and convenient as shouting very loud in the opposite direction when talking to someone.

OK, so would this work even without the AltGr turned on?http://www.keyboard-layout-editor.com/#/layouts/50e35007460bfc76b6b52050de50209b


æ is on Fn+Z


Æ is on Fn+shift+Z


ø is on Fn+V


Ø is on Fn+shift+V


å is driven by diacritics and is Fn+= to generate the sticky °, then A.


Å is driven by diacritics and is Fn+= to generate the sticky °, then shift+A.


Throughout the above, the right Alt remained right Alt and never had to be switched to AltGr.

æ has to be on æ

ø has to be on ø

å has to be on å

ä has to be on ä

ö has to be on ö

ü has to be on ü

ḉ on ḉ ñ on ñ and so on and so on.

The only way to do that, is have the keys that these letters are supposed to be. In terms of available pyra choices its to be as close to the english default as possible, so that you can easily incorporate them if needed.

You will also find the ^ key in this cluster of keys. If you press that and something else, you get for example ^+a =ä Much better idea than to print these things where they dont belong.

And then you can make the keymat. Less hackery all around.

 

[Grench]

I think æøå are missing. And i would never buy that if i could get its other qualities elsewhere.  If i had it i would probably try to use it socially, get annoyed, put it away.


Writing o for ø in Norwegian is about as socially acceptable and convenient as shouting very loud in the opposite direction when talking to someone.

OK, so would this work even without the AltGr turned on?http://www.keyboard-layout-editor.com/#/layouts/50e35007460bfc76b6b52050de50209b


æ is on Fn+Z


Æ is on Fn+shift+Z


ø is on Fn+V


Ø is on Fn+shift+V


å is driven by diacritics and is Fn+= to generate the sticky °, then A.


Å is driven by diacritics and is Fn+= to generate the sticky °, then shift+A.


Throughout the above, the right Alt remained right Alt and never had to be switched to AltGr.

æ has to be on æ

ø has to be on ø

å has to be on å

ä has to be on ä

ö has to be on ö

ü has to be on ü

ḉ on ḉ ñ on ñ and so on and so on.

The only way to do that, is have the keys that these letters are supposed to be. In terms of available pyra choices its to be as close to the english default as possible, so that you can easily incorporate them if needed.

You will also find the ^ key in this cluster of keys. If you press that and something else, you get for example ^+a =ä Much better idea than to print these things where they dont belong.

And then you can make the keymat. Less hackery all around.

Sorry, those keys do not exist on the primary layout.

http://en.wikipedia.org/wiki/QWERTY#United_States

I have explained repeatedly why your dream is simply not possible.

I have shown you, repeatedly, how we can make provisions in the layout to service your symbol creation needs.

You continue to insist on a pure Norwegian layout.  That isn't going to happen.

You are going to have to compromise or simply be left out.

 

[bzar]

Isn't there too much focus on multi language support?

I'll hazard a guess that MOST future pyra owners do not speak english as their primary language. Don't you think it's a good idea to maybe try to cater to that majority, as long as we also keep other priorities (english, programming, etc) in mind?
I'll readily admit again that the above is a guess. I also think the layout should first be designed for english input and symbol compatibility, but right after that it should support inputting other languages.

Here I come barging in again with another lay-out.

This time, again Pandora compatible but with Standard US shift pairs on the Fn layer and broad diacritic support.

How is the Fn implemented in this layout?

 

[_wb_]

I think æøå are missing. And i would never buy that if i could get its other qualities elsewhere.  If i had it i would probably try to use it socially, get annoyed, put it away.

Writing o for ø in Norwegian is about as socially acceptable and convenient as shouting very loud in the opposite direction when talking to someone.

If we take all sorts of colour-blindness into account:

colourbling.png

What do you mean, æ ø å are missing? In my proposal, they're on ◆F, ◆G, ◆T, and they're labeled as such.

In your layout proposal, I don't see any æ ø å. Your proposed mechanism is to remap the [{,  <> and Shift keys to those Norwegian letters, meaning you end up with a keyboard where the key labels no longer correspond to the key actions, and which no longer has a keyboard shift (forcing Norwegians to only use shoulder shift).

You worry about color-blindness, but in your proposed solution, there is no label at all for the letters you consider so important. I guess that means your proposal works equally well for people with regular vision, for the color-blind, and for the fully blind.

 

[MrConfusion]

Isn't there too much focus on multi language support?

I'll hazard a guess that MOST future pyra owners do not speak english as their primary language.

Yes, there is too much focus on this!

Simply given the option of a keyboard with either ready to use nonmapped (Fn!) keys or even a default numpad but out-of-the-box software to map those keys to national chars, I'm sure most people would take it and be happy. You map them, you remember them...

And my guess is that although most future Pyra owners probably do not speak English natively, most of them will spend so much time bickering on these forums IN ENGLISH that their fancypancy native symbols remain unused anyways! I fully intend to, myself!-)

Here's my Fn-LCNTRL on the Pandora:ä, both triggers: Ä

Here's my Fn-LALT on the Pandora:ö, shifted: Ö

Here's my Fn-RCNTRL on the Pandora:å, shifted: Å

Here's my Fn-RSHIFT on the Pandora: ½, shifted: ½

They don't read on my keyboard, I'm not expecting anyone else to ever consider this practical, but it is PERFECT for me.

As you might notice that last one is clearly for convenience - but I need it, often, so being able to map it myself was very useful even though it even isn't a commonly used character. And lobehold, I could still map it to a different symbol shifted.

If you, Comradekingu, want a norwegian keyboard, then map yourself one when the Pyra comes - if you actually use it you'll start remembering the key positions in no time.

 

[ible]

You worry about color-blindness, but in your proposed solution, there is no label at all for the letters you consider so important. I guess that means your proposal works equally well for people with regular vision, for the color-blind, and for the fully blind.

We should also design for snow blindness.

Seriously we should probably all chill on the keyboard layout making until there are some cullings.

 

[MrConfusion]

The backlight for the keyboard better be dimmable, because there'll be so many symbols on the keys it'll bleed light like it was a gardening lamp and look like a christmas tree decorated by a 7 year old with infinite budget...

 

[bzar]

Isn't there too much focus on multi language support?

I'll hazard a guess that MOST future pyra owners do not speak english as their primary language.

Yes, there is too much focus on this!
Simply given the option of a keyboard with either ready to use nonmapped (Fn!) keys or even a default numpad but out-of-the-box software to map those keys to national chars, I'm sure most people would take it and be happy. You map them, you remember them...

As long as I don't have to overmap anything and can get shoulder + some sensible key for my äö this is OK by me. The moment I overmap anything from the default layout I lose compatibility with any pyra software that assumes keys are in specific positions or easily available.
EDIT: Fn keys can not be easily remapped if Fn is implemented as hardware- or driver level modifier as it usually is. It should not me used as a name for a software modifier.

 

[_wb_]

I think I managed to make an international layout that basically does not require anyone to remap, and you don't have to remember the position of your åöä or éèçà or whatever it is you need, because they're actually labeled:

http://boards.openpandora.org/topic/18016-comparison-matrix-for-keyboard-layout-proposals/page-7#entry383416

The backlight for the keyboard better be dimmable, because there'll be so many symbols on the keys it'll bleed light like it was a gardening lamp and look like a christmas tree decorated by a 7 year old with infinite budget...

The number of symbols per key in my proposal is pretty modest: 2 symbols on most keys, 3 on a few, 4 on none.

But yes, the keyboard backlight will be dimmable .

 

[comradekingu]

The labels for öäü are not predominantly important, having keys there to press is. Typing is a exercise of stringing together buttons you know the position of.

There is both the convenience of having them where they are supposed to be, and the efficiency of having them be dedicated. Visuals are a bonus.

People who type on non-english keyboards instantly know where their extra letters are. The link between ◆ and something in the colour of ◆ is different, because ◆ is not an already expected and known paradgimn. Its not like colour-blind people exist in vast numbers, but nonetheless, the more people you include and the more concerns you are aware of, the more pyras sold.

Take the word for shy/reserved, and how to write/type it in different languages.

shy              s-h-y                             English

huraño        h-u-r-a-ñ-o                    Spanish

schüchtern  s-c-h-ü-c-h-t-e-r-n         German

förtegen      f-ö-r-t-e-g-e-n                Swedish

Notice how ñ ü and ö are all in the same place?

View attachment 11193

If you reference that against the English one, you will find the default is closer to English than anything else.

The whole difference is that its now much easier for 80 million Germans, 46 million Espanians, and 9 million Swedes to type like a keyboard/typewriter works.

 

[Eight Bit]

I'll hazard a guess that MOST future pyra owners do not speak english as their primary language. Don't you think it's a good idea to maybe try to cater to that majority, as long as we also keep other priorities (english, programming, etc) in mind? I'll readily admit again that the above is a guess. I also think the layout should first be designed for english input and symbol compatibility, but right after that it should support inputting other languages.

I think the primary layer should be complete enough to write regular english with in my opinion. Because of that the . and , need to be on the primary layer also.

Although on my big keyboard I have them on the bottom right, I chose to keep them on the left for Pandora compatibility. I'm already used to having those there and having the Fn key on the bottom right.

It seems no more than logical to keep all symbols of the same kind on the same side of the keyboard so I made a cluster that I think will be convenient enough for both coding and writing on the bottom left. typing your desired character should be easy enough by controling the Fn and/or Shift with the right thumb (mash), and pressing the wanted keys with the left without having to cramp or stretch your hand at all.

I think I achieved sort of a standarisation by (though on the Fn layer) having the shifted pairs together like they are on a standard US keyboard. Again, the Fn+Shift is easy accessable together with both the left and right hand.

As there's so many languages and so many letters, my idea for multi language support is to just make the standard layout support all those letters with the 8 dead diacritics, and make the rest available through compose (Fn+Space mash).

Atleast that way everyone can start writing in his or her own language out of the box. All dead diacritics are in the top right with most of them unshifted so it's very easy to access them quick I think.

Any personal mappings can be done on the empty keys in a dedicated segment of the keyboard, or on the Alt Gr layer.

As germany is one of the main markets for the Pyra and the ß can't be made with the dead diacritics I did add the ß in the standard lay-out. (so much for consistency)

How is the Fn implemented in this layout?

In my idea Fn functions as a hardware layer. It would not be registered as a key press by the software but would alter the keycode of the existing keys on kernel level, effectively doubling the amount of keys the pyra has. (I hope that makes any sense)

The shoulder Fn would act as an Fn lock, not real Fn. This could be handy when one wants to have 2 separate triple layer keyboard maps (Regular, Shift and Alt Gr).

It opens up so many options...

 

[WizardStan]

The shoulder Fn would act as an Fn lock, not real Fn

If I understand correctly, that would mean the Fn shoulder cannot be used in games. If it doesn't produce a keycode there's nothing for anything in user space to catch.

 

[Eight Bit]

The shoulder Fn would act as an Fn lock, not real Fn

If I understand correctly, that would mean the Fn shoulder cannot be used in games. If it doesn't produce a keycode there's nothing for anything in user space to catch.

No, the idea was that it is a soft Fn, used trigger the real Fn and when pressed together, to lock it.

Not sure if something like that is possible at all.

 

[WizardStan]

Well, you said

It would not be registered as a key press

so I'm not entirely certain how you are planning to do this at the software level. The keyboard Fn doesn't produce a keycode, so what does the shoulder Fn produce?

 

[Eight Bit]

Hmm, well, think with me...

How could this be solved without removing the Fn (lock) from the shoulderbutton?

If it's impossible I'm afraid the Fn has to move away from that location, maybe make the one that's left on the bottom right sticky for convenience?

 

[codifies]

Well, you said

It would not be registered as a key press

so I'm not entirely certain how you are planning to do this at the software level. The keyboard Fn doesn't produce a keycode, so what does the shoulder Fn produce?

Why not? there's no reason for it not to - in fact it *really* should have its own key code....

 

[comradekingu]

You missed me at what kind of problem it was that you were trying to solve.

If you provide standard US key-pairs when its on, i think its safe to assume the same would be wanted for those users also when they play games.

If its a "sometimes, but only with broken software" id say fix the problem at its root instead.

Using buttons on non-generic functionality and setting a trap for the user to enable it without knowing, is not ideal.

If you want it, enable it as a toggle on an opt-in basis on FN+something you wont press by accident.

Edit: I think you need "num lock" to type ALT-codes, which is a similar thing that could have a way to enable it for the people who have use for it.

 

[WizardStan]

How could this be solved without removing the Fn (lock) from the shoulderbutton?

Well that's exactly what I'm asking, I don't understand what you're saying.You've said "It would not be registered as a keypress" and I've asked "why not?" and "if it's not a keypress then how is it read by applications?"

From the way you keep talking about the shoulder button specifically as "Fn (lock)" I get the feeling that there's some kind of confusion going on but I just can't figure out what.

 

[Saber]

Updated the layout again. 

• Various mode toggles/reboots described.
• Locked mode specified. 
• Print and legacy keys, Pause/Break, Scroll Lock, and Number Lock added. Both apparent and hidden, yet accessible(if needed). 

A list of Compose key sequences can be found here.