Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nuklear: A single-header ANSI C GUI library

github.com

Post reply on HN
Print view View original

71–80 of 186 posts

Re: Nuklear: A single-header ANSI C GUI library

#71

Post by mwcampbell »

pkaye wrote: post #57
gnud wrote: post #26

Earlier quoted context omitted.

Additional advice: "don't use this toolkit if you ever want to sell your product to government".

Which is interesting because I use a dialysis machine and these are essentially sold to the government instead of the patient yet they all use a custom GUI interface like this one. Far as I can tell there is no accessibility features.

That's a difficult case, because it's a dedicated device and not a general-purpose computer. Adding a screen reader to such a device could be costly. Of course, these days, even a lot of "embedded" projects use Linux, some embedded flavor of Windows (previously CE, now Windows IoT Core), or even Android. Still, the device would need audio output. And to really cover the bases, for deaf-blind people, it would need to connect to a braille device via USB or Bluetooth.

In my ideal world, all user interfaces would run on the user's main portable computer (currently a smartphone), controlling devices remotely over Bluetooth, NFC, or the like. Embedded UIs would then be a thing of the past, and accessibility would simply be a matter of following the recommended practices for mainstream general-purpose platforms.

Re: Nuklear: A single-header ANSI C GUI library

#73

Post by mwcampbell »

mwcampbell wrote: post #17

Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640

Technical follow-up: It seems to me that implementing today's platform accessibility APIs (e.g. UI Automation for Windows, AT-SPI for Unix) would be difficult if not impractical for an immediate-mode toolkit like this one.

These accessibility APIs expose a tree of UI objects, which the client (e.g. screen reader) can freely navigate and query. This basically assumes that there's a tree of UI objects in memory, which is the case for all mainstream toolkits as far as I know. But that's not the case for an immediate-mode toolkit. At least with Nuklear, the content and state of the UI (e.g. the label and current checked state of a checkbox) aren't stored anywhere in the toolkit's data structures. So I guess applications would have to play a very active role in implementing accessibility APIs, much more than they would with, say, Qt or even Win32.

Re: Nuklear: A single-header ANSI C GUI library

#74

Post by jstimpfle »

TeMPOraL wrote: post #46
pka wrote: post #36

> No global or hidden state Does that mean that one can detach an input field, save its state somewhere, create a new one and attach it somewhere else again and have it appear exactly as it was before (i.e. cursor position, selection, focus, etc)? That's one of the pain points with VDOM frameworks (i.e. need to diff around UI components which shouldn't lose state), so I'm curious if this library gets it right.

There is no "input field", the UI state is entirely on your end :). This is immediate mode UI. It handles inputs and renders simultaneously. Consider a line from the example in the README: nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f); That line is responsible for both drawing the slider (at a place determined by value, with min = 0, max = 1, step = 0.1) and setting the variable `value` to whatever position user is cu…

> It handles inputs and renders simultaneously.

I'm not sure that's the point. I think it's a good idea to decouple input and output (render).

The point of IMGUI vs traditional toolkits is, I think, rather that you don't have to communicate through an API to manipulate and sync state with the framework/library. The latter imposes lots of communication overhead and second guessing, and can't offer the same level of control.

Re: Nuklear: A single-header ANSI C GUI library

#77

Post by billsix »

random_upvoter wrote: post #70

As a small criticism, looking at the project page I get no clue whether this library works on Microsoft Windows.

Yes it works on windows.

Hopefully this does not come across as rude, but from the readme

"It was designed as a simple embeddable user interface for application and does not have any dependencies, a default renderbackend or OS window and input handling but instead provides a very modular library approach by using simple input state for input and draw commands describing primitive shapes as output. So instead of providing a layered library that tries to abstract over a number of platform and render backends it only focuses on the actual UI."

Under the demo folder, there are examples.

Nuklear works with opengl 2 and 3 both with sdl2 and glfw (both of which support windows) it works with direct 3d 9 and 11, with gdi (windows specific libraries)

Re: Nuklear: A single-header ANSI C GUI library

#78

Post by billsix »

ericjang wrote: post #75

Nice. I also recommend checking out Nanogui (C++) by Wenzel Jakob: https://github.com/wjakob/nanogui

The reason that I love immediate mode GUIs like nuklear and dearimgui is that, unlike callback based GUIs like nanogui, qt, gtk, wxwidgets etc, I do not need to learn how the framework Works internally in order to use it effectively.

The lack of callbacks in particular, means that I do not need to worry about memory management very much. Or, I should say, I don't have to defer memory management to later.

I own books on wxwidgets and on qt. To be honest, although I've read them fully, I still don't quite know how to use them well, nor how would I teach teammates how to even if I did.

Using a tool like dearimgui or nuklear, I have no books, but 95% of the time I can just copy example code from the demo into my app, modify it slightly for my needs, and call it a day.

Re: Nuklear: A single-header ANSI C GUI library

#79

Post by satysin »

badsectoracula wrote: post #53
c-smile wrote: post #38

Earlier quoted context omitted.

With .h only files, when you need to include needed functionality, you modify only your own source file. But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools. Think about the whole zoo: Visual Studio, XCode, Code::Blocks, make, NMake, etc.

Why you need to do that with .c files? You can just drop the .c/.h pair into the same place as you would put the single .h file and the rest of your C/C++ files and use it like that.

You are free to split it into .h and .c if you want, every single header library I have used has an IMPLEMENTATION block to make doing so very simple.

Re: Nuklear: A single-header ANSI C GUI library

#80

Post by billsix »

jstimpfle wrote: post #74
TeMPOraL wrote: post #46

Earlier quoted context omitted.

There is no "input field", the UI state is entirely on your end :). This is immediate mode UI. It handles inputs and renders simultaneously. Consider a line from the example in the README: nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f); That line is responsible for both drawing the slider (at a place determined by value, with min = 0, max = 1, step = 0.1) and setting the variable `value` to whatever position user is cu…

> It handles inputs and renders simultaneously. I'm not sure that's the point. I think it's a good idea to decouple input and output (render). The point of IMGUI vs traditional toolkits is, I think, rather that you don't have to communicate through an API to manipulate and sync state with the framework/library. The latter imposes lots of communication overhead and second guessing, and can't offer the same level of co…

When you say, draw a button in an immediate mode gui, the widget is drawn for this frame, which has not yet been flushed to the monitor. Yet the draw button function returns true or false on whether it was clicked. But how can that be, this button has not yet been flush to the display?

The imgui framework handles the previous frames events when drawing the current frame.

This implies that the only concept you really need to know using an immediate mode GUI framework, is that internally to the framework it needs some mechanism to identify objects between frames.

Post reply on HN