Nuklear: A cross-platform GUI library in C
github.com
github.com
Check the sokol-headers integration example here, this should properly detect short touchpad taps:
It seems that scrollbars don't loose input when the mouse is not over them, but slider widgets do (that would be a Nuklear specific problem).
For the problem that an app might lose mouse input when the mouse moves outside the window boundary, this must be handled differently depending on the underlying OS. For instance on Windows you need to call SetCapture() [1]. The platform integration isn't handled by Nuklear itself, so you'll see different problems like this pop up depending on how carefully the platform integration has been implemented (the official samples should be in better shape though I guess).
[1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...
I've been on the fence for a couple of months over this -- I want to grab an M1 Mac for R&D type stuff, but at the same time I want to wait until they release the 16" with a hopefully upgraded M1 of some sort.
Thing is, I literally just bought this maxed out i9 less than a year ago and it works perfectly!
Only 7 of the 24 compilers in the list fully implements C99 whereas I would guess all those compilers implement C89. If you want to write long-lived programs, C89 is a good choice.
(last I checked a year or two ago)
Like writing secure software, until this becomes a legal requirement no matter what, it will keep being ignored by the large community of developers.
"no matter what"? One of the more popular uses for these immediate-mode UI toolkits is to create interfaces for video games, either debug UIs or the menus painted over the game's main scene/content. I don't think people who need a screen reader are going to be playing a twitch-reaction shooter game.
I agree that these shouldn't be used for general use applications, but I strongly disagree with the sentiment that somehow all programs should be forced to work with screen readers. Some domains and applications are primarily visual and don't really translate well to textual interaction. I think these kinds of toolkits work best with those kinds of applications.
You shouldn't use these to write the next Discord or Slack or Firefox or LibreOffice etc. -- but I don't see a problem with making a debug UI or a menu for an action video game with an immediate mode toolkit.
Realistically, however, even if this is only/mostly used for games (if so, why doesn’t https://github.com/Immediate-Mode-UI/Nuklear even mention the word game?), many, if not most, of them probably will be turn-based, because it’s much easier to write such games.
Also, accessibility doesn’t imply screen reader. It also includes high-contrast, larger fonts, tabbing through controls (e.g. to support users with Parkinson or motor disabilities), etc. Nowadays, a GUI library should pick up settings for those from the OS.
If it's possible for someone to beat these games blindfolded (at a competitive pace, no less!), then it's possible for a blind person to beat it too.
The old consoles didn't have screen readers, but watching zallard1 play Wii Punchout blindfolded, I can see where they would help. Amazing fights, yet painful to watch when using the menu system.
Outside of that lack of randomness, I doubt there are any purposeful or even accidental affordances towards blind players in those games.
I feel there are plenty of reasons to not write your own anything, from prioritizing other projects, not having time, or just not having all of the required expertise. As a student I'm lucky enough to be able to drop basically everything and work on this one cool project idea so long as I get my essays in on time, but that just doesn't seem to be something universally applicable.
> instead of complaining on the Internet
Where else would you prefer they complain? I agree it may be more effective to open an issue no the repo, but does that also count as `copmlaining on the Internet'? Talking to people is how we change things. In this case, that's contributing to the usability of technology that grows ever more central in our lives.
Personally, I think a focus on accessibility is a great focus to have, and it should be obligatory if it isn't voluntarily universal. There is no reason for our society to provide more opportunities to humans with perfect vision than to humans with impaired vision.
For America it already is. The ADA covers software, too afaik
And I generally like Qt, but I can see how you might consider it heavy and a bit unwieldy.
My impression, from looking into this a bit a few months ago, is that cross-platform accessibility is just a huge effort, and may be beyond the reach of projects that lack commercial backing.
> It was designed as a simple embeddable user interface for application
so, at least rhetorically, it is more generic/general than for video-game use.
"Game Maker's Toolkit" does an overview of accessibility in games: https://www.youtube.com/watch?v=RWQcuBigOj0
Having said that, I think The Last of Us 2 needs to be studied more as they appear to have done an amazing job with accessibility, given that a blind player was able to complete it. Maybe other developers can learn from that.
[1] And a personal pet peeve of mine: pixel art games using pixellated fonts. I find most pixel fonts extremely difficult to read. When I posted about that on r/gamedev once I just got yelled at because "artistic vision", but your artistic vision is useless if I can't play the game. At least give me the option to use a normal, crisp font.
"mostly for video games, so not really a concern" should be downvoted, not the people who say that games should think about accessibility.
Not sure if commenters posting about accessibility have a disability themselves or are speaking up for people with disability. However reality is that in total it is a small percentage of users and without guidelines or having a disability yourself it is really hard to work towards. Especially at least from what I have seen in games the variety and range of disability. Without good guidelines and accessible interfaces for aiding tools. So requiring a gui library without funding to have a high level of accessibility or labeling it worthless is a somewhat cheap way of judging these libraries.
Current accessibility APIs are tightly coupled (conceptually and logically) to APIs that originated in the 80s: Win32 and Cocoa.
If you're only using native widgets it's virtually automatic to have full accessibility. But as soon as you need minimal customisation you have to interact with extremely verbose APIs. Cocoa's API is much better, but MS's Automation API is very arcane and complicated, and even MS employees acknowledge that.
On top of that, even if you're using the APIs as intended, the examples provided by Microsoft are low-quality and are not a good starting point for implementing accessibility on non-native.
Thus, only giant corporations have the resources to fully re-implement accessibility in non-native applications. Google can do it in Flutter and Chromium (Electron). Nokia for Qt. Facebook for React Native. But single developers just don't have the power to do it on their lightweight libraries.
What we need is a smaller lower-level accessibility API that gives accessibility to game engines, non-native UI toolkits, TUIs and command line apps. But I don't think there's much incentive coming from OS makers to do it.
You forgot AT-SPI2: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/
Take for instance a Webbrowser. You could implement one using ncurses, etc. like links, lynx, etc. But for the screen reader this is just a terminal window with a bunch of text.
A Gui can help the screen reader to know which part to read when and how it releats to other parts of the GUI.
Also as a blind person, you live in a world of people that see. You cannot expect every developer to take care and cater to your needs. A GUI that takes care about this automatically for the developer means the dev can just continue doing their thing. While the blind people, can benefit from it as well.
1. Disabled person not the one who controls what gets run.
2. Disabled person not the one who controls what is installed on device.
3. Joint use by two people of the same app.
4. Disabled person wants to be able to ask someone for help who can interact with the app "fully".
Take features like voice control for example where a motion impaired person can still enjoy visually rich content. https://youtu.be/aqoXFCCTfm4
Does anyone have any good resources?
[0]: https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility
[1]: https://en.wikipedia.org/wiki/Microsoft_UI_Automation
[2]: https://stackoverflow.com/questions/65168795/make-non-native...
Edit: IAccessible2 [3] seems to be compliant to both Windows and Linux. Whether Apple AppKit provides specific accessibility-focused UI elements [4]. Flutter has also similar one, it is called Semantics [5].
[3]: https://wiki.linuxfoundation.org/accessibility/iaccessible2/...
[4]: https://developer.apple.com/documentation/appkit/nsaccessibi...
[5]: https://api.flutter.dev/flutter/widgets/Semantics-class.html
This is possible at least for restricted domains: I've personally written software for image processing for text extraction and application steering from high frequency screenshots of a Windows app that didn't have an automation API.
Also: The DeepMind Starcraft 2 AI plays at a high level in real-time from, AIUI, an image stream.
https://sourceforge.net/projects/dyndlgdemo/files/
https://github.com/MikeDunlavey/AucUI
He explains it a bit more here:
https://stackoverflow.com/questions/371898/how-does-differen...
I wonder why he arrives at the conclusion that he needs a full-fledged DSL for what he is doing. I remember that at the time I was working on this, the impression I had was that a lot of my problems would go away if only there were some unique way to identify every distinct invocation of a function (so I could use data along the lines of "you are currently in the 3rd call of Button() in something.cpp"). __FILE__ and __LINE__ get close but don't disambiguate between multiple calls on the same line (and anyhow would need to be baked into the invocations with macro hackery).
[1] The prevailing use of hashing is a consequence of the popular immediate-mode UI libraries being focused on minimal state per widget. If you already plan to maintain significant state for every widget (as you would need in an immediate-mode interface to win32 controls) you would just do hierarchical interning with sequential id assignment (i.e. the first time a new subid is used with a given parent, it is assigned a sequential global id and put in a table so the association can be memoized across frames) and then hash collisions won't cause id collisions.
(On the off chance you're curious, I just pushed some previously unpushed updates to that experiment I had sitting around, so now it has labels and text entry too. I guess the real test of the architecture would still be making an alternative "rendering backend" based on win32 widgets or something.)
The real hack is implicit IDs, not the ID stack (which is just a way of implementing a hierarchical namespace like file system paths or URLs). Implicit IDs just work 99% of the time and rarely require manual intervention, so seeking a 100% solution is a tempting siren song. But once you actually start writing UIs like this, the 99% solution is just fine.
That's a good point.
(a) hash the entire call stack (though that might produce false negatives, i.e. consider two UI elements that should be the same distinct?)?
(b) put the burden on the reusable function to mark itself as such by pushing/popping an identifier of its own call site on the ID stack?
> The real hack is implicit IDs, not the ID stack (which is just a way of implementing a hierarchical namespace like file system paths or URLs). The fact that implicit IDs just work 99% of the time and only require manual intervention 1% of the time is a false siren song into letting you believe a 100% solution is desirable (you have to consider the marginal cost of what it would entail).
Well, this is just the standard problem of library design, isn't it? You always have to figure out the appropriate tradeoff between supporting rare cases and making common ones easy. (Of course, you can often do both; in this case, you probably could both give "explicit ID" and "call site ID" versions of each UI element API.)
The differential execution approach is to "diff" the GUI by "diff"ing the program's control flow. As opposed to something like React where we're diffing the virtual-DOM output of the render().
During a GUI update the program is run comparing it's new control flow with the prior run. So for example on an IF statement, if the prior execution took branch A but the new run takes branch B, then we need to run branch A again in "erase" mode to erase everything created by branch A, then run branch B to create the new state.
example: https://pbs.twimg.com/media/EuQ-6vzXUAca_Ph?format=jpg&name=... (ignore the fact the UI goes from bottom to top, that will be fixed)
A cross platform gui library needs to have consistent layout across all platforms so it has uses basic flexbox layout algorithm instead of the native macos constraint system, I think this turns out better anyway because flexbox is a lot simpler in my mind. It decouples the layout algorithm from the UI code so you don't need to rerun your whole UI whenever the window changes size. It uses pure c++ native calls instead of objective-c which is kind of crazy but the library user never needs to interact with it
The first reason is that it doesn't have a good layout system requiring manually specifying positions and sizes in quite a few places and doesn't gracefully handle varying font sizes. My GUI code is littered with x*FONT_SIZE to do some kind of scaling to work on my low res 27" screen and a high res 13" laptop. I don't need it to do any magic behind the scenes with font sizes (such as moving from monitor to monitor), just allow setting the GUI font size to a reasonable value and sticking with it without manually specifying every row height.
The motivation for this probably is that the author wanted to have extremely skinnable UI to be able to do fancy game UI's. However, if you look at a lot of modern game UIs they have a flat "material design" type of UI with flexbox-like layouts, and no fancy skinning, just flat colors and rounded corners. Another motivator is that Nuklear can run on triangle-based GPUs and pixel-pushing APIs. This is not valuable to me.
The second reason is that it's buggy. The developers have taken to the extremes to avoid dependencies. This includes stuff like home-brewed implementation of printf. Which will hang in an infinite loop when you try to print a float that has INF value. With some hacking, I was able to make Nuklear use standard printf and some other standard library functions instead of the bundled implementations.
I appreciate all the effort the developers have put into this, but it's not ready for prime time and expect to spend time fixing bugs if you'll use it.
I'll probably be moving away from the immediate mode GUI paradigm as a whole (instead of using Dear Imgui or Nanogui), it's a poor fit for the application I'm developing.
Recently I've been seeing a quite polished game UI toolkit used in several published games, like Rise of Industry and Space Haven. Does anyone know what this toolkit is? Something Unity offers or some proprietary library?
On my spare time I've also worked on a retained mode flexbox-based UI layout and rendering library that integrates like Nuklear or Dear Imgui. In other words, the GUI library doesn't have any dependencies or have any side effects. You feed in a tree of GUI elements, the events coming from the windowing system and as output you get a vertex buffer and a list of triggered events. This concept shows some promise but unfortunately I don't seem to have the time it takes to turn this into a polished product. I'm happy to talk about it if anyone is interested.
Your post has made it clear that I should stick with Dear ImGui and figure something else out for in-game UI. I'll probably roll my own simple thing (I'm just playing around for fun, so I can afford to do that).
printf isn't a part of the freestanding C standard, and neither is snprintf. That said, there are portable freestanding snprintf implementations out there with permissive licensing.
See https://immediate-mode-ui.github.io/Nuklear/doc/nuklear.html...
The text editor gcc doesn't have any dependency, but you must provide it a backend so it can do its text editing. The example uses a nano backend written in C, but you can provide any other backend like vim or emacs, it's just a handful of functions to implement and is usually not too hard.
Its still a dependency in my books, but its not the same as saying "this requires DirectX" or whatever: it requires a backend, but you can give it any backend you want, so ideally wouldn't pull in anything you aren't already using.
Makefile.glfw3
Makefile.freeglut
Makefile.gtk
Makefile.x11
Makefile.cocoa
But as it is now, it is presented to be like glfw3 is a hard dependency.
For these imgui toolkit, it is just a few lines of code if you know what you are doing. For the library authors, it is quite a bit of work to maintain different environments and CIs to test all these backends though.
The examples somehow need to connect to the underlying operating system, and that's why they depend on GLFW as intermediate layer, but this could also be SDL, or - shameless plug - the sokol headers (https://github.com/floooh/sokol), or (more commonly) a game engine like Unity, Unreal Engine, or your own code.
The appeal of nanogui to me is that it's built on top of OpenGL.
Just wondering if anyone has used a decent pure jvm immediate mode gui library before or have suggestions on immediate mode libraries in general to try out?
For what I am thinking of trying it out with, my needs aren't too high so I might just write something simple with libGDX/lwjgl3.
With more focus on GPU integration, and output quality. Unfortunately, these priorities resulted in more than an order of magnitude of code complexity, compared to Nuklear.
For instance, nice but fast anti-aliasing is hard. 16x hardware MSAA is often OK in terms of quality, but too slow on platforms like Raspberry Pi.
I did a CTRL+F for "sciter" and usually I find something, but this time, nope.
More generally - is this really something that's missing? I mean, hasn't something very similar already been implemented (as FOSS, I mean)?
The only thing missing for me to use it would be Vulkan support. I'm sure it will land soon and if not I guess I can put in the effort and make a patch/PR. =)
The big missing features were VLAs (those will never be implemented) and _Generic (implemented now in VS2019).
_Generic has only been added very recently in VS2019, and MS recently has pledged C11 and C17 support (but it will never be a C99 compiler because VLAs will not be implemented, that's fine though, VLAs should never have made it into the standard).
There is no rule that ISO C++ compilers should be C compilers as well.
In fact, I bet they only backtraced on their position on their C compiler due to WSL, IoT and devices like Azure Sphere.
Lots of legacy targets have shoddy-at-best C99, or new, support.
You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers.
Is that true? I thought low-level game development was almost entirely in C++. Why is there resistance to using libraries written in the same language as the rest of the program?
There are easy to integrate C++ libraries like Dear ImGui but they are in the minority, and (for instance) Dear ImGui uses a very restricted set of C++ features (it's essentially "C with namespaces and overloading", so it's not very far removed from a C library).
And this is the main reason why is written in a subset of C89, because is 100% source compatible with C++.
char* bytes = malloc(4);
Here's for example such an "implementation source file" example (using stb_image.h):
https://github.com/floooh/sokol-samples/blob/master/libs/stb...
...or for a whole collection of related single-file libraries:
https://github.com/floooh/sokol-samples/blob/master/libs/sok...
Very nice
Wouldn't this defeat the purpose of having an immediate-mode API ?
Off topic, but also a pleasant reminder of something I used to enjoy quite a lot.
[1] http://www.nuklearpower.com/2001/03/02/episode-001-were-goin...
Join the discord https://discord.gg/V69VdVu
Quite a few people have been using it to build their own GUI. Add some layout, windowing and event handling and you have yourself a GUI.