Add a Modifier state to Keyboard variant

[bvssvni]

See https://github.com/PistonDevelopers/piston/issues/613

Keyboard(key, Modifier { shift, ... })

so you can do

Keyboard(keyboard::A, Modifier { shift, ... }) if shift =>

pub struct Modifier {
    shift: bool,
    ctrl: bool,
    gui: bool,
    alt: bool,
}

[dpc]

If this is to be generic solution, maybe left and right keys should be separate. I could imagine people in their games might want to use left and right keys differently.

It is not a big hit to do:

Keyboard(keyboard::A, Modifier { lshift, rshift, ... }) if lshift|rshift =>

[bvssvni]

We could have 3 bools, one for both sides and one for both.

[dpc]

I guess it's a good idea.

[dpc]

There's also super and maybe others?

[bvssvni]

I think it's called LGui and RGui.

[bvssvni]

I think the most common case is to just track the common state. We could drop the left/right side since these are easy to track manually when needed.

[dpc]

Why to make something that handles only 75% of the cases, when one can have 100% solution?

[dpc]

It seems yes: https://github.com/AngryLawyer/rust-sdl2/blob/master/src/sdl2/keyboard.rs#L63

[bvssvni]

bitflags!(
    flags ModifierKey: u8 {
        static Shift = 0b00000001,
        static Ctrl = 0b00000010,
        static Alt = 0b00000100,
        static Gui = 0b00001000,
    }
)

[dpc]

And how will I know was it left or right key? :)

[bvssvni]

NumMod, CapsMod can be separated to another structure to not collide.

[bvssvni]

When you match against Shift, you don't want to match against Ctrl. In this case we can use bitflags, but not a struct.

[bvssvni]

The user expects matching against Ctrl to support logical OR against both sides, while logical AND against Ctrl + Shift.

It seems that GLFW thought of this or it might be a lucky guess.

[bvssvni]

Todo:

• [x] Add ModifierKey to 'keyboard.rs'
• [ ] Handle modifier key in sdl2_game_window
• [ ] Handle modifier key in glfw_game_window
• [ ] Make suggestion for KeyboardState which shall contain num lock, caps lock etc.

KeyboardState should probably be struct to allow logical OR matching.

[bvssvni]

I think caps lock and num lock only matters for text input. By leaving them out we can match against a shortcut by using a tuple.

[bvssvni]

The suggested solution conflicts with the usage of FirstPerson.

[bvssvni]

What we can do is add ModifierKey and add methods that updates state.

[bvssvni]

I'm sorry, but this can't be implemented while abstracting over buttons like we want for input mapping.

Instead I've added a ModifierKey which makes it easier to keep track of the state. See https://github.com/PistonDevelopers/input/issues/42

Closing.