UI Toolkit

[jonbonazza]

A proper UI toolkit is integral to the success of any game engine. This goes beyond basic buttons and labels, but also has to deal with things like containers, layouts, input pass through and blocking, etc...

There are a few GUI libs out there for Go, but these all suffer from a couple problems:

1. Most of them don't provide a way to use an existing OpenGL conext (assuming they use OpenGL for rendering at all, which is a different issue all together).
2. None of them support multiple render targets (i.e. opengl, metal, vulkan, etc..)
3. None of them would tie in with our existing Input subsystem.

As such, I suggest that we build our own UI toolkit that is tailor made to fit the rest of the engine's design.

Although tedious (and as such, this is a rather large undertaking, no doubt), layouts and UI controls are all well understood and solved problems, so it won't really be difficult work.

The design here should utilize Engo's ECS framework.

I'll start by stubbing out a basic framework and present it for feedback before working on actual implementations of the various controls and layouts.

[yarbelk]

Just to necro post (again), Some thing I'd like to see in the UI toolkit is support for textual and data heavy games (so; tabs, spreadsheets, heavy use of copy-paste, modal and window support)

The games I want to play are heavy on the simulation side, and golang is awesome for me because they fall in the 'embarrassingly parallelizeable' computational space

if you want to go down a structured definition language route; I've been playing on and off with the concepts you see in QT; but instead of a turring complete javascript; target a simpler system (or; at the very least, less awful).

QT's Signals and Slots are a good starting point, though would need to be rehashed to be more golang idiomatic and make better use of go routines and channels. They may work well with the message system. for my toy project I was looking at haiku's aggressivly threaded model as well, which is also a good fit for UI; but may have major performance impacts in a game engine.

[Noofbiz]

Now that we have Arcs and Beizer Curves in common.Shape, I'm thinking we could actually get started on this. Honestly, I'd suggest sticking to the ecs paradigm in engo itself. This way, when we change it to add concurrency etc then the UI stuff would utilize just be updated to utilize that.

No worries about brining back these threads, it helps us know which features are important to people! Thanks!