Add Keyboard Support to Canvas

[corranwebster]

What is the problem or limitation you are having?

The Canvas widget is has no keyboard handling. It would be useful to be able to do things like scroll a plot using arrow keys or capture simple keyboard input for games.

Describe the solution you'd like

Add a callback for keyboard events on the Canvas widget. The callback should be given the key pressed as a Toga Key expression, along with any modifiers, and ideally the text that results from that key combination with the current keyboard layout, if any.

Describe alternatives you've considered

Leaving it as is, and implementing a more robust input handling system at a higher level that is independent of the Canvas widget. For example the proposal doesn't handle composed keys or entering text in Chinese/Japanese/Korean. These require additional special handling which should be its own subsystem (see eg. hoe Gtk handles composing characters).

Additional context

This is related to #3994 in so far as the Canvas element can have keypress handlers. Looking at how HTML/Javascript handles key presses may give a guide to the information that is passed to the callback.

[freakboy3742]

Agreed this could be useful. I'd be a little concerned about the performance if people actually try to use the canvas to write a game, but at least conceptually, I agree the capability for keyboard handling should be there.

The scroll use case is an interesting one - my question would be whether scrolling should be caught and handled by a ScrollContainer that contains a canvas - or, at least, how that would be possible to support as an option.

[corranwebster]

Agreed this could be useful. I'd be a little concerned about the performance if people actually try to use the canvas to write a game, but at least conceptually, I agree the capability for keyboard handling should be there.

Yep, certainly not good for high-end games or 3D, but it should be able to handle puzzle games or old-school retro stuff. The performance question is relevant, but certainly the underlying native widgets are capable of reasonable performance when rendering.

The scroll use case is an interesting one - my question would be whether scrolling should be caught and handled by a ScrollContainer that contains a canvas - or, at least, how that would be possible to support as an option.

Usually when scrolling/panning in a plot you want to keep the position of the axes fixed and only change the the rendered plot inside the axes and axes tick marks or grids, the way that Matplotlib does it for example. That's usually not a good fit for a scroll-bar interaction, because the scrolled region would need to be embedded in the Canvas.

[freakboy3742]

The scroll use case is an interesting one - my question would be whether scrolling should be caught and handled by a ScrollContainer that contains a canvas - or, at least, how that would be possible to support as an option.

Usually when scrolling/panning in a plot you want to keep the position of the axes fixed and only change the the rendered plot inside the axes and axes tick marks or grids, the way that Matplotlib does it for example. That's usually not a good fit for a scroll-bar interaction, because the scrolled region would need to be embedded in the Canvas.

That's definitely true of a Matplotlib style canvas; but the other example is something like InkScape (or any other vector art program), where you're moving a viewport around a canvas that is much bigger than the viewport. In that case, you wouldn't want to capture the keyboard events (or, at least, the "move" events) at the level of the canvas - you want the scrollcontainer to scroll.

I can't think of a good example where you'd want both, other than something very artificial like a very large Matplotlib chart on a very small device... so it might be acceptable to rule that out as a use case.