Edits: fix ephemeral links.
Because I have seen an increasing number of stars/watches etc on my QT based editor at https://github.com/JSandusky/UrhoEditor I’m starting this thread so that persons interested can be aware of what is going on and where it is as well as state their items of concerns.
Superficially it looks like it’s been static … but it really hasn’t been.
Recently I have been exploring avoiding data-binding in order to minimize the woes of GUI programming. Because I use the same code-base for that QT editor and a different project it is often difficult to reconcile the two. A lot of potential is lost in dealing with the data-binding woes of retained GUIs. Reconciling Core Urho3D and “my version of Urho3D” has been unpleasant to say the least. Never mind that I intend this toolset to be usable outside of Urho3D.
In trying to find ways to make exploratory efforts and easier UI I gave IMGUI paradigms a shot. For this I turned to Nuklear as it has a draw scheme that fits QT whereas IMGUI does not (barring writing a barycentric-rasterizer in QT … good luck with that).
The results were excellent. While Nuklear’s widgets are very janky, I’ve already put in the effort of making several of them (text edit and slider) less janky and more usable. I will continue to do so for other widgets as is viable.
In the UI pictured above there are more than 1k draw commands being issued to QPainter per IMWidget (6 of them) and there is no consequence on the real-time performance of the viewport. It’s viable … that’s just a debug build.
Once the editor is bound to AngelScript I believe that this approach will give Urho3D users the same editor powers that Unity users have … if not much more by virtue of having the source.
Progress has been happening, even if you don’t see it in github. So many options are opening up, prepare for an influx - this is a geyser.
- Why no CMake files?
- CMake hates QT, it was a shit-storm to compile Aster’s QT particle editor on windows via CMake, a complete shit-storm … it just doesn’t work - you’ll get things working faster doing it yourself
- CMake falls on its face when dealing with code generation, this project will very quickly encounter automatic reflection scenarios that require code generation
Note: I do not consider Nuklear suitable for Node-graphs … I’ll be exposing the node-graphs used for the texture graph editor in a couple of weeks. Node-graphs really do need to be retained, they’re systems of often absurd consequences.