Here are some musings about creating a better framework for people to create Panda games in. This is not intended to be a complete design, just some ideas on what it could look like.
It should be theoretically possible for multiple applications to run in the same process space. This is useful in networked environments(where a server and client might be separate applications that communicate) and helps facilitate the development of in-app editors(where an“EditorApp" might manipulate the running application’s App). Also, on Android, multiple app instances may run in the same process space.
Desktop: Inherently a(multi-)windowed/2D environment, where 3D elements are added to the 2D window(s) to visualize a 3D world. Input could include touch, but is primarily keyboard/mouse. App controls lifecycle.
Mobile: Inherently a single-windowed 2D environment, where 3D elements are added to the singular window to visualize a 3D world. Input could include keyboard/mouse, but is primarily touch. OS controls lifecycle.
VR: Inherently a windowless 3D environment, where 2D GUI layers might be composited spatially over the scene by the compositor.(But the app may still open a desktop window to give outside spectators something to see.) Input could be keyboard/mouse, but will more likely be motion/buttons.
Promote good development and user experience practices
Make asynchronous programming easy(and encourage it by default)
What should it NOT do:
Be a singleton(should be possible to have multiple instances on separate threads)
Be cluttered with non-application-wide member variables(eg. scene graphs, etc.)
Integrate with third-party libraries(eg. tk, wx)
Applications wishing to do this need to provide such integrations themselves
Set up everything and the kitchen sink(physics, collisions, etc.)
There will be facilities for setting this up, but the App class is not the right place.
Require use of DIRECT
Write anything to builtins
Give user full control over main event loop(complicates Android/WebGL/*OS)
Be difficult to use
Put more concretely - a“hello world” should consist of about one or two dozen lines of Python(not counting comments). The“hello world” should also be a natural first step to a full app(i.e. it should be possible to start with a sample and iteratively/gradually modify it into a complete app all on its own)
What functionality should the class encompass?
OS application features
Name, identifier, icon
Foreground state(on Windows, which does not have per-app foreground state, we easily emulate this by checking if any of the app's windows are in the foreground)
Application context menu
Contain launch parameters
eg. which intent the application was run with on Android
Restrict running multiple instances at the same time, if desirable
Perhaps turn its launch parameters into a config page?
Paths
Manage cache directory
Provide paths to save logs, game state, etc.
Pausing, saving state
Required on Android, since OS may kill app at any moment to free up resources
Encourage developers to write their app from the ground up to make pause/resume easy
Panda or OS can automatically pause(perhaps even save) game when users switch away from it
Earlier work
App class
Goals