yarbelk
commented
4 years ago 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
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:
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.