[Rejected] Region Specific Keyboard Input

[MatijaBrown]

Summary of the PR

As I promised a while ago, I would be implementing a way to make the input API care about keyboard layouts, so that, for example, on a German keyboard Z is returned, when the z key is pressed and Y.

The primary intention is to add a base API so that it will be easy to implement new keyboard layouts and also implement a few myself.

[CLAassistant]

All committers have signed the CLA.

[HurricanKai]

I would like to see this be optional/configurable somehow. In games for example, Z typically means the bottom left key, instead of the character Z, similarly to how W/A/S/D are the arrow keys on the left, instead of the literal characters.
Initial idea would be a culture like Api surface, where there is an invariable keyboard layout and the system selected one.

[MatijaBrown]

I would like to see this be optional/configurable somehow. In games for example, Z typically means the bottom left key, instead of the character Z, similarly to how W/A/S/D are the arrow keys on the left, instead of the literal characters.
Initial idea would be a culture like Api surface, where there is an invariable keyboard layout and the system selected one.

Of course it will be possible to turn the adapting on and off. I am planning to make it so that it can either be set to a certain layout or be automatically adapted, so if, for example, one is developing a game and wants z to be the bottom left, just change the keyboard layout to US-Layout and it will work as usual.

[Perksey]

Agree with what Kai said. Please make sure you create a proposal we can review in documentation/proposals before working on the actual implementation.

[MatijaBrown]

Agree with what Kai said. Please make sure you create a proposal we can review in documentation/proposals before working on the actual implementation.

I do agree with what Kay said, sorry if it was not obvious from my reply.

[MatijaBrown]

I have added a proposal a while ago. Is this what you expected Kai, or did I misunderstand the message?

[HurricanKai]

We can discuss this with the ARB as-is, but some early comments for your consideration.

[HurricanKai]

I don't think an enum is the right choice here - I feel using inheritance for this would be better.

[MatijaBrown]

One could definitely use inheritance there, the reason I put an enumeration is because this is only meant for the user to set the keyboard layout. I thought about each of the layouts being abstracted from the KeyboardLayout class, but that would mean having to write an own implementation for custom keyboards, while this way one can easily just set a flag. But I guess inheritance would be possible as well, if it fits better.

[HurricanKai]

My idea would've been that we have some pre-defined instances like KeyboardLayout.QWERTY which would just implement an interface. I think that'd make for the most flexibility while keeping usage equally simple. Of course some boilerplate on our side, but I don't think it's too much

[MatijaBrown]

That's probably the best way, I agree, but what about custom layouts? Just have a KeyboardLayout.Custom? That would work, just be a lot different from the others.

[HurricanKai]

That'd be a problem with enums, but with static properties that just return different implementations of an interface, a custom layout would just not work via KeyboardLayout
instead I'd be something like Layout = new MyCustomKeyboardLayout()

[HurricanKai]

I'm guessing slkLyt is SilkLayout? So not some standard format?
Why is that favourable over

public sealed class MyCustomLayout : IKeyboardLayout
{
    public Key MapKey(Key original)
    {
        // probably a switch statement or whatever
    }
}

I guess having those files mean the user of our user can modify it, but I'm not sure if that's a thing we want to force?

[MatijaBrown]

That is just a way of storing the layout. (I just made up a file extension, in this case yes, silkLayout). It just maps a key code to another, just like that method. Only, instead of the giant switch statement, I thought one could use a Dictionary to map the keys and load the data from a file. That would mean not writing these long switch statements and easier configurabillity. Also, then it would be possible to have a generic Customlayout class that just takes in the file.

I could also just leave out the custom layouts for the beginning and only add the existing ones, then I wouldn't have to bother with that at all, and it wouldn't be to hard to implement later either.

[HurricanKai]

I mean I guess we can provide a separate type that loads a file - but I don't think the inbuilt ones should also be based on such files.

[MatijaBrown]

Sounds good. So I guess I'll change the proposal documentation to be up to date, and then contact you again.

[MatijaBrown]

I have committed a few changes to the proposal file. Is this better?

[HurricanKai]

What does this do?

[MatijaBrown]

NoLayout means using the standard layout (The same as QWERTY, but the standard layout, not QWERTY, they just happen to be the same).
LastLayout is just the count of layouts, if this would ever be requiered.

[HurricanKai]

If we keep this class as-is, it can be static

[MatijaBrown]

The Get() methods are static because I believe it to be nicer that way, but one could just as easily use a constructor.

[HurricanKai]

Only thing I'm unsure about here is what does QWERTY mean? Will on, for example, a German keyboard Y be mapped to Z and Z to Y?
Unshure, just feels a bit weird.

[MatijaBrown]

Only thing I'm unsure about here is what does QWERTY mean? Will on, for example, a German keyboard Y be mapped to Z and Z to Y?
Unshure, just feels a bit weird.

QWERTY is the name of the keyboard layout (US) that GLFW uses. These (Also QWERTZ for germany) are the official names instead of having LayoutManager.GermanLayout. (Although, there might be QWERTY_Uk and QWERTY_Us, there are slight differences.

Also, sorry for not congratulating you on videre, so I wanted to do it now.

[Perksey]

API needs work.

Discussed in working group meeting 5th March 2021:

• use scancodes?
• can't do this right now, but use scancodes - improve friendliness in some workloads (e.g. location of key)?
• just add a scancode enum, much easier
  • fyi https://kbdlayout.info/kbduk/download/kbdtables
• is it even our job to be region specific? input system doesn't know much about text or buttons anyway...
  • most we'll do is a extension package containing a bunch of scancode mapping enums.

[MatijaBrown]

API needs work.

Discussed in working group meeting 5th March 2021:

• use scancodes?

• can't do this right now, but use scancodes - improve friendliness in some workloads (e.g. location of key)?

• just add a scancode enum, much easier

  • fyi https://kbdlayout.info/kbduk/download/kbdtables

• is it even our job to be region specific? input system doesn't know much about text or buttons anyway...

  • most we'll do is a extension package containing a bunch of scancode mapping enums.

• The idea with the scan codes is extremely good! Whoever had that idea - congratulations to you.
• Other than that, I don't quite see what you are getting at - not in a "my API is perfect" way, I just don't know what other
  significant API changes could be done, if there are any, just tell me, I am open to improvements.
• If Silk.NET should provide that functionality is for you (as in, the Silk team) to decide. The reason I opened this PR is because I
  complained so much about Z being Y on my keyboard that someone suggested I added it to Silk.

[Perksey]

I think the general consensus was that this API of this scale just isn't necessary. As discussed in my notes from the meeting, the most we'll probably do is an extension package containing a bunch of region-specific enums which map scancodes to key names.

[Perksey]

How come this has been closed? Can you remove the changes from other files so that we can merge in the rejected proposal for future reference?

[MatijaBrown]

How come this has been closed? Can you remove the changes from other files so that we can merge in the rejected proposal for future reference?

I closed it as there doesn't seem anything more to discuss? Or did I miss something?
I didn't change any other files - if so, then it's only some miss click while browsing the code. I'll remove that then as well.

[Perksey]

We tend to merge in even rejected proposals (with (Rejected) in the filename of course) so we have an easily-accessible record of ideas people have had for the library.

[MatijaBrown]

We tend to merge in even rejected proposals (with (Rejected) in the filename of course) so we have an easily-accessible record of ideas people have had for the library.

Oh, alright - well, as far as I know there's no other change.

[Perksey]

Cool, once the other file changes have been reverted I'll merge this in.

[MatijaBrown]

One small question here, how do I revert the file I accidentally changed? I can't seem to do it without leaving a new commit message, which is obviously not intended.

[Perksey]

Just leave a new commit message, we squash PRs down anyway.

[MatijaBrown]

Then everything should be reverted.