If you have a zig project that needs a GUI, try DVUI.
Unlike most immediate mode GUIs, DVUI works at low and variable framerates, and processes every input.
It’s suitable for normal applications as well as debugging windows on top of games.
The web demo will give a quick idea of what the current capabilities are.
Let me know what you think!
Hey man I tried your library and I just wanted to say that I absolutely love it!
The only thing I personally find strange is that creating a widget doesn’t require you to specify a dvui-window. It makes me wonder how it would be possible to run multiple windows on a single thread once async may be re-implemented, which is admittedly something you should probably never do, but I think should be possible.
This is just my opinion, though. I am not a professional developer and only have about 3 years of private on-and-off coding experience.
I don’t wanna sound too negative though, this message is meant to be seen as a compliment and appreciation of your software. I hope that you will keep maintaining it.
Thanks very much!
That decision was to support a design goal of being able to sprinkle some dvui code in a part of a larger project. Think a game where there’s some part of it you want a gui display to help debug, but you don’t want to have to thread a dvui-window into that part of the code somehow.
There is support for having multiple dvui-windows as long as they are handled sequentially. But as far as I know nobody has really tested that ability.
All that said, dvui is still quite new, so only time will tell if those choices turn out to be right or if they need to change.
Thanks for the feedback!
Ah yes I understand the reasoning for not needing to specify the dvui-window now. Honestly I don’t think I would’ve done it different and adding opt-in-specification now would probably be a non-trivial change.
One question, when will the mach-backend support probably be back? I’d love to see the binary size once I don’t need sdl any more.
I’m very excited about mach and fully intend to get that working again. The main problem is that the mach people move so fast it’s hard to keep up!
Do you (or anyone else reading this) know if now is a good time to get a mach backend working again? Should I target webgpu or the new sysgpu?
Unfortunately I don’t. I have very high hopes for the mach library, thinking it has potential to become the de facto standard high quality everything-graphics-library for Zig in the future but I haven’t checked in on their development yet.
I guess you could @ slimsag
I think just making a 0.13.0 mach backend release wouldnt hurt, although I dont know how much work that is and how close 0.14.0 is by now
Okay I’ll take a closer look. It shouldn’t be a problem unless mach is using a version of zig that’s not compatible with 0.13 - I know they’ve been doing a process where they pick a more recent zig version regularly.