ShowBase replacement ideas
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.

Earlier work

App class

Goals

What should it do:
  • Encapsulate an independent application
  • 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.
  • Contain application-wide state (through composition)
  • Manage application lifecycle state machine
  • Manage the system event loop
  • Be implemented in C++
  • Support Desktop, Mobile and VR paradigms
  • 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