I’m largely posting this thread to move discussion away from this GitHub issue and to gain some input from the userbase.
We’re looking to deprecate libRocket, which is (was) great in that it’s a resource-based GUI framework - it runs (ran) on the HTML-derived RML language for expressing a GUI independently of programmer assistance. Unfortunately, it’s abandonware and not compatible with Python 3.x, so unless someone’s willing to step forward and maintain it, we’re not going to be able to continue supporting it.
There are far better options out there these days; so rather than trying to add yet-another-directgui-alternative, we should probably try to pick something that would fit most use cases for Panda app developers, and thus can be a more “standard” Panda GUI toolkit.
I’m probably heavily biased by my own perspective, but the way I see it, what’s important here is:
- Lightweight: Should not add more than about a dozen or so MB to the built binary size.
- Resource-based: Your team’s GUI designer should be able to edit the GUI with minimal/no coordination with your team’s programmer.
- Procedurally-friendly: Not every app developer cares to put special attention into creating GUI resources; sometimes one simply wishes to hammer out a quick “setup_gui()” function that places all of the widgets. A procedurally-friendly interface would be nice - but note that any resource-based framework is necessarily procedurally-usable, since an app can always create the necessary resources on-the-fly.
- Performant: We’d like the GUI toolkit to generate as few draw calls as possible - pgui, for instance, is heavily dependent on the Panda scenegraph, which means full transform changes and primitive batches for each widget.
- Portable: Should run equally well on desktop and mobile (and other) platforms; should not assume a single rendering API (e.g. so it can target GL, Direct3D, Vulkan, etc.)
- Flexible: Ideally, it’d be nice if the toolkit didn’t assume it was a 2D overlay running in screen-space. This allows for widgets to be spatially positioned in the scene, with GUI interactions driven by ray-casting and/or VR controller point-and-click.
- Embedded+standalone?: A nice-to-have feature would be a GUI toolkit that supports rendering both within a 3D framebuffer, and onto a desktop using the platform’s native windowing system. This means that teams familiar with the in-app GUI toolkit can easily use it to create out-of-app GUIs as well, or perhaps create interfaces in which the Panda viewport is yet another widget itself.
- Usable both from C++ and from Python: As many developers prefer the C++ interface to the engine; it should be easy to set up a GUI using pure C++ code.
- Permissively licensed: Ideally under BSD/MIT license so that the terms of using the GUI toolkit don’t differ substantially from the terms of using Panda3D itself.
To that end, I tried to narrow this down and find some options myself. We can effectively split the choice here between HTML-based and non-HTML, so I’ll list each:
Chromium Embedded Framework
- Pro: Permissively licensed under BSD.
- Pro: Works either embedded or standalone
- Con: Heavy! It’s about 100MB in size.
- Con: May not be very portable, as Chromium itself has a lot of OS-dependent code.
- Con: Although it does work standalone, it’s an odd choice that can’t easily be made to resemble the desktop’s native GUI framework.
- Pro: Much lighter weight than Chromium
- Pro: Permissively-licensed
- Con: Not a full HTML implementation
- Pro: Developed by the Awesomium author
- Pro: Purpose-built for this exact use case
- Con: Not open source. Trying to support non-x86 platforms? You’re completely out of luck.
- Con: Very restrictive license, of the “we want to know how much revenue you’re making” sort.
- Pro: Multitouch is a first-class feature
- Pro: Includes the Kv design language, making it somewhat resource-based
- Pro: Implemented primarily in Python, making the interface very comfortable for Python users
- Pro: Mobile support is a primary objective
- Con: Not usable from pure C++
- Pro: A very popular framework, with which many F/OSS developers are already quite familiar.
- Pro: QML is a great, resource-based approach to GUI design
- Pro: Very usable from pure C++
- Con: Not very usable from Python - bindings for Qt5 are available, but as yet somewhat immature.
- Con: Might be too heavy.
- Con: LGPL license may be too restrictive for some use cases.
- Pro: Lightweight
- Pro: Popular
- Pro: Good license
- Pro: Easy to use from C++
- Con: Not resource-based; GUI must be implemented in code
- Con: Immediate-mode operation means the GUI code must run in the draw thread - if Python-based, means the Python GIL will be held while drawing and block the app thread
What are everyone else’s thoughts?