Refactor `KeyEvent` and `KeyEventEventArgs` to simplify

[tig]

The keyboard handling code has gotten super crufty over time.

We have:

• KeyEvent - Originally designed to be passed to functions (before .NET event EventHandler stuff) as an abstraction above the drivers
• KeyEventEventArgs - Recently (clumsily) renamed to match modern patterns. Basically just holds a KeyEvent
• ProcessKey, etc... = Don't match our event pattern (should be named OnKeyPressed etc... Takes a KeyEvent
• There is no KeyPressed event. There should be. It will use KeyEventEventArgs making ProcessKey/OnKeyPressed weird for taking a KeyEvent

This all results in a lot of confusing and ugly code that is ripe for hard to find bugs. E.g.

I want to simplify this. I did a prototype and it worked well, but I screwed up and lost the work.

Plan:

• There will be one class, 'KeyEventArgsdefined in./Input/Keyboard.cs. It will merge KeyEventandKeyEventEventArgs. KeyandKeyModifiersdefns will move toKeyboard.cs too (Event.cswill be renamedMouse.cs`)
• The Responder methods ProcessKey, ProcessHotKey and ProcessColdKey will
  • Be renamed to OnKeyPressed, OnHotKeyPressed, and OnColdKeyPressed and the signature will be bool OnKeyPresssed(KeyEventArgs args)
  • Be accompanied by new events (KeyPressed, KeyDown, KeyUp). There is no need to add Hot/Cold key events, because we want people to use the Command framework for that anyway.
• All library code will be updated as needed. Where it makes sense, events will be used instead of overriding the On methods. In some cases I may move code to use Command to reduce code.
• All Scenario code will be updated as well.

This will be a massive PR in terms of files touched.

We will also want to do the same thing to Mouse handling.

Thoughts?

[BDisp]

• All library code will be updated as needed. Where it makes sense, events will be used instead of overriding the On methods. In some cases I may move code to use Command to reduce code.

You need to pay attention with this one. If you use KeyPressed, KeyDown, KeyUp and Handled = true before Application class send them to the View class, users cannot handles them first. But if Handled is never set, then there is no problem. Just a note.

[tig]

• All library code will be updated as needed. Where it makes sense, events will be used instead of overriding the On methods. In some cases I may move code to use Command to reduce code.

You need to pay attention with this one. If you use KeyPressed, KeyDown, KeyUp and Handled = true before Application class send them to the View class, users cannot handles them first. But if Handled is never set, then there is no problem. Just a note.

Good call. Do you happen to know if there are any existing unit tests that ensure this?

[BDisp]

Good call. Do you happen to know if there are any existing unit tests that ensure this?

To my knowledge, no. But we can make a View subscribing KeyPressed, KeyDown, KeyUp, MouseEvent. If any of them wasn't called, then something wrong happened. Maybe is need to do it for the SizeChanged too.

[tig]

I'll make sure we have sufficient tests for this as part of this pr.