Virtual Keybard too GLFW dependent

[Zardoz89]

I'm finding that there some stuff on virtual Keybaord that is perhaps too depedent of GLFW :

• KEY_WORLD_1 What key maps ???
• KEY_WORLD_2 Idem...
• KEY_LEFT_SHIFT and KEY_RIGHT_SHIFT : Some libs not difference and simply handles a Shift scancode (for example Qt). I suggest merge to KEY_SHIFT
• KEY_LEFT_CONTROL & KEY_RIGHT_CONTROL : Idem
• KEY_LEFT_ALT & KEY_RIGHT_ALT : Idem

[milesrout]

LCTRL/RCTRL (similarly LALT/RALT, LSHIFT/RSHIFT) being distinct is a good thing, in my view. This seems like a reduction in functionality. There are more than a few applications that depende on the distinction between left and right modifier keys.

[Zardoz89]

I'm agree with you. But it, makes very hard to use anything different of GLFW to handle keyboard input. I think that should be less GLFW dependent. And a awful quantity of libs not difference between left and right modifier keys.

[milesrout]

You can use QKeyEvent::native{VirtualKey,Modifiers,ScanCode} in Qt.

[Zardoz89]

I see. Well, we can drop KEY_WORLD_1 & KEY_WORLD_2 as isn't very clear what maps

[adam4813]

Those from what I gather are keyboard maker defined and aren't the same
between any.
On Mar 20, 2015 3:40 AM, "Luis" notifications@github.com wrote:

I see. Well, we can drop KEY_WORLD_1 & KEY_WORLD_2 as isn't very clear
what maps

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

[Zardoz89]

Doing a little research looks that was common on the 80's, to have keyboard with multiple Shift, Alt (Symbol) or Control keys that not generate different scan codes.
In some cases, this is because are a backwards compatible with a previous model that only had a single key instead of left/right X keys (ZX Spectrum +2/3 case). there there is others like the BBC Micro , the Oric or the Apple 2 that always do this. I think that different scancodes for left/right X keys are more exclusive to PC's and Commodore computers.
So, I'm going to unify left/right X modifier keys.

[milesrout]

You should not unify the left/right modifier keys. It's a pointless reduction in functionality.

[milesrout]

We already use GLFW so the dependency (which isn't actually a dependency at all) is not important.

[Zardoz89]

But, if we need to change to other lib ? ( I hope that not). Also, the specs not should enforce GLFW stuff. I think that we not need to enforce to anybody to use GLFW if someone try to write an emulator from scratch (in special if him is using an language were using GLFW isn't viable).

I know that is a reduction of functionality. And I was to keep intact left/right modifier keys differentiation on scancodes. But I realized that :

• No body is using it.
• It was very usual on the 80's.
• It's a bit more simpler to use.

[milesrout]

But, if we need to change to other lib ? ( I hope that not). Also, the specs not should enforce GLFW stuff. I think that we not need to enforce to anybody to use GLFW if someone try to write an emulator from scratch (in special if him is using an language were using GLFW isn't viable).

Then we don't change to incompetently-written crap that doesn't support left and right modifier keys. Left and modifier keys isn't "GLFW stuff", it's just normal keyboard stuff.

No body is using it.

Nobody is using anything.

[Zardoz89]

No body is using it.

Nobody is using anything.

Actually there is two firmwares that does something and is using the keyboard and the floppy drive.
It isn't much, but isn't nobody.

Well, we can undo the unify left/right modifier keys.