- 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.
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.
Glad to see one person (@elcritch) is working on this. ;-]
Just want to note that it took a lot of reading to become aware of the figuro project. Is it too soon to add it to https://github.com/nim-lang/Nim/wiki/Curated-Packages#gui or https://github.com/ringabout/awesome-nim ?
I guess my concern is that a web search about Nim GUI libraries will point to lists of bindings and incomplete/abandoned projects, with no mention of figuro. I think more promotion of the project might not only help it but the Nim language by showing people the current active direction in this realm.
Maybe we would benefit from a different general list of active projects that people can contribute to.
A "1.0" release might not be too far off. I'd definitely like a scaleable text editor in place. Though the current text view panels handle pretty large text already. I've been using it to read markdown version of Hacker News. Just being smart in breaking up larger text into separate Text paragraphs should scale well for many apps.
Actually scaling issues will be around handling large number of nodes. Currently updating layout does the entire tree. Generally with Nim that's fast enough for now, but probably will only scale to ~1000 nodes for 60fps? Still that wouldn't be a block for a 1.0 release as it's just optimization.
My main goal now is making finishing a basic set of widgets including menus. That's important because it's also creating (finding) the idioms and patterns for making apps with Figuro. That's needed because it's a hybrid of web and native GUI programming approaches. Handling stuff like HTML web components slot mechanism, etc or more tradition MVC stuff, etc.
@derek-v-s I appreciate the shoutout!