Native UI development for Nim: https://github.com/nim-lang/uirelays
Extracted from NimEdit so we have some evidence the API scales well. It supports the development of custom drivers, the interface has deliberately been kept minimal.
Coming soon: A tiny DSL for layout computations.
Hi.
Two doubts: Will "uirelays" be having responsive layouts later? Also, the "touch inputs", in case needed for mobile experiments?
How is a UI library being compared to a game library?
I looked at the example code and it’s pretty much identical to what I’d write with raylib – there is a main loop where you react to events and draw the GUI using basic primitives like drawRectangle. I’m struggling to see any significant differences.
From what I can tell, this is an immediate-mode GUI with manual layouting? What are the advantages compared to mature options like Raylib?
That's essentially what it looks to be. Though with a bit of layout support now.
Overall the API would be good for simple apps, but looks hard to scale to more complex apps. Who knows where it could go though.
Start adding things like reusable combo boxes, lists, tables, theming, etc and it starts getting harder. It's sort of where I got to with Figuro and paused -- I'm not happy with ways to combine reusable components without MVC and/or OO patterns.
Meanwhile, I’m building an app in both figdraw and uirelays to learn them. And also submitting PRs. uirelays is wayyyy better than raygui. And I will not bother with C libraries again either. We can make better Nim libraries.
Definitely pure Nim libraries are better!
FigDraw is just to pull out the core rendering pieces and improve upon them. The idea is to provide a high performance renderer for others to build UI libraries on top. I'll probably port uirelays to FigDraw out of curiosity. :)
Start adding things like reusable combo boxes, lists, tables, theming, etc and it starts getting harder.
FWIW I'll turn NimEdit's syntax highlighting text editor into a "widget". It will get us quite far already. There is only text and images.
Theming seems to be a "relay-adapter". Seems easy enough to do.
There you go: https://github.com/nim-lang/uirelays/pull/9
Screenshot included.
Figdraw is great, thank you for creating it! In my simple timing benchmark, it was the fastest. It is indeed very low-level and could benefit from a widgets library.
Awesome! A widget library would be outside the scope of FigDraw. :)
It'd be easy to make an immediate mode UI library on top of it though! I did an LLM port of uirelays to use figdraw/siwin yesterday and it was simple. I'll make a PR for it soon.
Though I did add some helpers to FigDraw to draw lines and circles using the rounded-rect primitive.
We need FigDraw to handle complex paths (straight, quads, cubics with even-odd and cap)
FigDraw handles straight lines using a helper and could do even-odd/cap. Otherwise 99% of normal UI elements are just combinations of rounded-rects, SVG/icons, and text.
My current solution for icons / SVGs in FigDraw currently are MSDFs (multi signed distance fields textures). I was able to make a basic Lottie interpreter that uses FigDraw, Pixie, and MSDFs to do some basic shape animations. See: https://forum.nim-lang.org/t/13683#82905 and https://github.com/elcritch/lotty
Adding quad and cubic SDFs directly into FigDraw's renderer wouldn't be too hard. They just don't seem worth it to me vs just making a 64x64 MSDF that gives 90% or more of the fidelity of raw arbitrary bezier with scaling / squishing / etc.
with full and dotted strokes, fills, patterns...
FigDraw currently supports linear and trilinear gradients. Adding patterns, repeats, etc, would be great and cover a lot.
I can dedicate some time to support an svg subset if there is some interest.
That'd be cool!
Currently FigDraw can draw very simple SVGs now. However, to really make MSDF approach work it'd need to handle breaking up an svg into sub-shapes with MSDFs based on colors and the like.
I'll probably try to add support for filling rectangles with a texture and msdf texture pattern
Ohh that'd be awesome!