Added all numpad key definitions.

[cgkoutzigiannis]

Fixes #2220.
I added all numpad related GDK definitions.
I did find the correct definitions for the other keys as well, but I have a few questions about this.
Should toga differentiate between Left Shift and Right Shift(same goes for Alt and Ctrl)?
If yes, does that mean I should change the Key definition in core?
Should I add a test about this change?

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[HalfWhitt]

I missed this on my first PR too, but the reason a check is failing is that you need to include a change note. In this case it would be be named 2220.bugfix.rst and probably read something like "Previously unrecognized keyboard input is now correctly recognized on GTK."

[freakboy3742]

Should toga differentiate between Left Shift and Right Shift(same goes for Alt and Ctrl)?

No. Although there is a key-code difference (because they're different physical keys), functionally there's no difference between left-shift and right-shift for almost all use cases - you don't see menu items with "Left shift-Alt-X" shortcuts.

Should I add a test about this change?

As a general rule - any code change should be accompanied by a test. Ideally we'd include an exhaustive test of all keys, but I suspect that will end up with a very complicated (and slow) test case, for not a lot of gain. Unless you have any creative ideas, I think I'd be satisfied extending the testbed test_keys test to include a test of at least one numpad key (and any other edge cases you think might be interesting). This will likely require a change to each of the other desktop platform backends, as the keystroke test data is hard-coded into the testbed backends.

If you need any pointers on this, don't hesitate to ask.

As noted by the CI run and the comment above, you are also missing a changenote on this PR.

[Juan-de-Salgado]

Should toga differentiate between Left Shift and Right Shift(same goes for Alt and Ctrl)?

No. Although there is a key-code difference (because they're different physical keys), functionally there's no difference between left-shift and right-shift for almost all use cases - you don't see menu items with "Left shift-Alt-X" shortcuts.

Big use case: games.

[freakboy3742]

@Juan-de-Salgado If you're considering using Toga to write a game, you should probably reconsider your choice. Toga isn't a gaming toolkit. It's a toolkit for exposing native GUI widgets. Games are not a good match for Toga's feature set or capabilities, and they're not a use case that we're actively trying to accomodate.

[Juan-de-Salgado]

@Juan-de-Salgado If you're considering using Toga to write a game, you should probably reconsider your choice. Toga isn't a gaming toolkit. It's a toolkit for exposing native GUI widgets. Games are not a good match for Toga's feature set or capabilities, and they're not a use case that we're actively trying to accomodate.

Thanks for the reply. That said, the combination of a Canvas widget and a BackgroundTask is proving so far very handy for 2D animations. (I realize you don't plan to support an OpenGL widget as a priority.) Also, after trying for some months Android Studio, Kivy, Phaser and others I can't remember, I'd rather use Toga/Beeware and concentrate on programming rather than on fighting with a build. You guys are doing a fantastic job here.

At the moment my only little peeve is that set_full_screen is not yet implemented on Android.

[freakboy3742]

@Juan-de-Salgado If you're considering using Toga to write a game, you should probably reconsider your choice. Toga isn't a gaming toolkit. It's a toolkit for exposing native GUI widgets. Games are not a good match for Toga's feature set or capabilities, and they're not a use case that we're actively trying to accomodate.

Thanks for the reply. That said, the combination of a Canvas widget and a BackgroundTask is proving so far very handy for 2D animations. (I realize you don't plan to support an OpenGL widget as a priority.) Also, after trying for some months Android Studio, Kivy, Phaser and others I can't remember, I'd rather use Toga/Beeware and concentrate on programming rather than on fighting with a build. You guys are doing a fantastic job here.

Thanks for the kind words. And if you're having success using Toga to build a game, then by all means keep going! I'm just letting you know that if/when you start finding bugs or requesting features, "game focussed" use cases aren't likely to move the needle.

FWIW - for the gaming use case, I'd be a lot more interested in making Briefcase (as a deployment mechanism) work with Pygame (or another gaming toolkit). I don't have any plans to work on "Pygame for Android/iOS" myself any time soon, but I'd be happy to provide guidance if someone else were to look into that problem.

At the moment my only little peeve is that set_full_screen is not yet implemented on Android.

To clarify - are you sure you mean set_full_screen? Android windows essentially are full screen by default; is there some interpretation of full screen that I'm missing, or do you mean that you want an Android window without the green titlebar?

If it's the latter, the feature you're looking for isn't full screen, but #1870 - and there's a prototype implementation that I'm currently working on in #2244.

[HalfWhitt]

I have actually thought about how neat it could be to embed Pygame or something similar in Toga. Imagine something like Solitaire, with PyGame handling a surface for custom visuals and interaction, and Toga providing platform-native menus, buttons, preferences, dialogs, etc. It's not something I've looked yet into hacking together, but it's an intriguing use case.

[freakboy3742]

I guess that's not out of the question - after all, PyGame is essentially treating the entire app as a drawing surface, so it's probably not that far removed from making that drawing surface a part of an app.

I don't know how easy it would be to get PyGame to give up control of the App and/or app window. There's also going to be a bunch of complications with integrating the event loop, and any contention over resources like audio. And, of course, none of this addresses the Android/iOS port. However, it's definitely idea worth exploration.