- Non-native UI widgets. Highly controversial, I know, but I only use these different OSes because I have to, there is no value to me personally in using the native Coca-Cola widgets just because only these get subpixel polarization right. I don't care. What matters that it works on the common OSes and that it works well and consistently across the different OSes. And that it keeps working and survives a switch to yet another platform.
- Written in Nim with an idiomatic API and DSLs. Of course. But! It should be compiled to a DLL so that my build times don't suffer. ;-)
- It should offer a low level API too, powerful enough that custom widgets can be written easily.
- Multi-threading ready with clear rules what can be done in a background thread and what not and how to communicate between threads.
- It should support both the traditional "event based" mode and the even older "immediate mode" UI. And leave the choice to the final application which mode I need to work in.
- Small footprint. You cannot compete with Electron based apps so don't even try. Instead make it run everywhere where a browser cannot be afforded. This can imply that it works well on embedded devices, but also and more importantly that it can be used in security critical applications.
Nice to have:
- If you only work with the very high level APIs and restrict yourself to certain widgets, make it so that it supports a textmode UI as well.
- Do not know the pro/cons of such choice, but good looking is very important on major platforms.
- Do you mean OpenGl or such API?
- Good documentation and at least some mini apps that could be a code base to write an real application.
Are there some existing API that could be a starting point ? What should be the next move, in your opinion?
It should be compiled to a DLL
Oh?
- Multi-threading ready with clear rules what can be done in a background thread and what not and how to communicate between threads.
I think the lib should just have a boolean inBackgroundThread: bool parameter for those backgroundable proc. For UI most thing should be main thread for responsiveness.
- This can imply that it works well on embedded devices, but also and more importantly that it can be used in security critical applications.
Are there even GUIs that are cleared for mission-critical applications?
Nice to have:
- If you only work with the very high level APIs and restrict yourself to certain widgets, make it so that it supports a textmode UI as well.
If I were to write a UI library, given how hard and time-consuming it is to wrote UI libs, I would instead start with text first, especially because most people using Nim in productions are using it for CLI-based tools.
Once those are made very appealing, upgrade to GUI.
There is a lot to do with text-based UI already, status-bar, progress-bars, see https://github.com/Textualize/rich which IMO is the based console UI, and certainly the one with best docs, I've seen.
- It is usually done via canvas widget. So that widget is needed. And this mean just abilities to drawing in the library.
- Multithreading in GUI usually depends on a backend code. At the moment, only Vulcan and DX12 supports multithreading, OpenGL not. If you try to update GUI from another thread in, for example, GTK, there will be dragons. ;) Thus, the GUI library should be backend independent either, like Nuklear or ImGUI.
- That's require to write two libraries. :) Both approaches are mutually exclusive and require a separated code. Even a general concept how a GUI library works is separated for both ways.
- Small size: the point 5 is against this point. Details above. ;) Security-critical things usually require very expensive certifications. :) It could be done, for example, by formally verified the library.
- It is doable, I saw a couple of libraries which allowed that.
Isn't Fidget quite close to this?
I've come to believe that the most challenging piece with a custom GUI is text input. Even more so than text rendering! Well at least since Treeform did much of the hard work on fonts. :)
For text input you need to handle shortcuts, different alphabets, left-to-right, repeating inputs, etc. I believe it'd be worth considering reusing OS native text input, and I believe it's what browsers do (did?).
Well speaking of browsers, supporting a (sane) subset of html rendering would be an interesting approach: https://sciter.com/ :P Actually I always did think sciter was pretty impressive demonstration of what one person could do if focused. The author said it took him about 9 months of full time work.
Both approaches are mutually exclusive and require a separated code. Even a general concept how a GUI library works is separated for both ways.
I don't agree. It's mostly the existing distinction between peekEvent vs waitForEvent.
It is usually done via canvas widget. So that widget is needed. And this mean just abilities to drawing in the library.
Yes, but there is a difference between "here is a canvas widget" and "every widget was built on top of this canvas and so should be yours".
- The main thing: don't make users write layout trees in code by hand! Some declarative layout system is a must to grow out of toy demos. It doesn't have to be a full-fledged GUI-designer (I'm not naive enough to wish for something I used 20 years ago with Delphi). At least a DSL sprinkled with constraints is good enough.
- Please, make it boring. Don't try to add skins or animations until you have a tree element in your widget set. And when you have it, make it a checkbox tree. Don't compete with React, compete with Tk and Lazarus.
- Don't fully agree with the point about native (but I have no personal experience to state it authoritatively). The main thing, I think, is dealing with text. It's too hard unless you leverage what's available with the OS. Although, all the mentions above are not strictly native.
- Don't bother with the web version. You can't compete with web-specific frameworks and if your stuff works well, it will be ported to wasm/emscripten sooner or later.
zooming UIs
looks kind of like interactive((animated) svg + map server) + leaflet
Other backends (software renderer, NanoVG in Nim (no wrapper - like femtoVG in Rust), Nim native driver, ...) can follow when the FW has a good usability and some widgets are available. The developer can decide which backend to use for special hardware. I think there is a lot of other work to create a multitreaded Render-Tree, low-memory consumtion,
Building multi-threaded renderer honestly isn't too hard IMHO. Just convert your UI/widget tree into a set of more primitive non-ref objects to put them into a sequence to send to the render thread to avoid allocations. Especially when you build on others actual GPU renderer's!
The renderer runs super fast. The front end is another matter. Things like tables + re-draws can get expensive and slow.
The pattern of making simple render nodes to send to the renderer also makes it pretty easy to port the front-end to alternative rendering backends. I've been wanting to try porting Figuro to NanoVG or similar so I can try it an a raspberry pi or even esp32. Partly I'm curious what it'd take to run a nice UI on an ESP32 :-)
solid/responsive event-management, handling of dirty components, layout-system, composition and innovative extention API for creation of custom components and widgets in pure Nim, no DSL. I think Nims syntax offers a good declarative style.
Those are harder parts. Many of these UI systems have built these up over many years. New UI's like SiftUI's struggle with these for years despite having enormous companies like Apple behind them. Flutter UI apparently struggled for years with text input box refresh performance on many platforms, etc.
You can get pretty basic UI elements up pretty quickly, the fine polish is harder. Handling font styling, theming, etc are all tricky. I found aspects like default colors or sizes for widgets to be tricky. How do you override them efficiently from a user context, etc.
IMHO, many of these pieces can be handled by separate libraries. Layout systems can in theory work with most any widget system or event system.
I gave libagar a spin with futhark. Works great.
This is the hello world example from their docs.
import futhark, strutils
importc:
path "/usr/include/agar"
"agar/core.h"
"agar/gui.h"
{.passl: "-lag_core -lag_gui".}
assert 0 == AgInitCore(nil, 0)
assert 0 == AgInitGraphics("")
var window = AgWindowNew(0)
let label = AgLabelNew(window, 0, "Hello, World!")
AgWindowShow(window)
assert 0 == AgEventLoopProc()
# libagar install cmd for Arch Linux, adapt to your OS
$ pakku -S agar
# futhark runs into a compiler limit, work around with loop iterations
$ nim c --maxLoopIterationsVM:100000000 agar.nim
$ ./agarEt voila, a window.
That was a lot easier than I thought.
Now I wonder if libagar is any good! Looks comprehensive for sure.
I dont care for subpixel polaristion
Please do!
If you mean subpixel rendering/aliasing/hinting (= aliasing using colors, not just gray tones), the absence of it lets fonts look blurry. Example in the below Image (part of a bug report).
Please do!
Nah, that's like GPU support. Once you have widgets and portability and it working on 80% of the platforms that Nim runs on, you can care about subpixels and GPUs.