Wow! This is the first time I'm seeing a project having two licenses. MIT and unlicense. You can choose whichever you want.
Nuklear: A single-header ANSI C GUI library
41–50 of 186 posts
Re: Nuklear: A single-header ANSI C GUI library
#42I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file?
It's really a godsend. include it and you're done.
Re: Nuklear: A single-header ANSI C GUI library
#43I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file?
I've actually seen some projects where it's organized into a bunch of files, but then they export/"compile" to a single header file which is what you include in your project.
Re: Nuklear: A single-header ANSI C GUI library
#44Before 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
Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames . A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).
Point taken. Some games, though, could be accessible if not for the way the UI was implemented. For example, repackaged text adventures. I downloaded the Lost Treasures of Infocom app for iOS, and it was completely useless with VoiceOver. Presumably because the dev at Activision who was working on this packaging used the same kind of UI toolkit that they always use for games. The same goes for turn-based strategy games, if it's feasible to provide text for all the graphics.
Accessibility for games is definitely a much lower priority than accessibility for applications that are used in business, education, and everyday communication/social networking. Still, a blind person can feel excluded if their friends are playing a game that they can't play. Sometimes a given game can't be made accessible without changing the whole game mechanic. But that's not always the case. So, something to consider.
Re: Nuklear: A single-header ANSI C GUI library
#45You can't build a "ANSI C GUI library", because ANSI C has no graphical capabilities.
C, the language, doesn't come with e.g. a MySQL driver either, but I'm pretty sure you can write one in C. If you're going to be pedantic at least be correct.
Re: Nuklear: A single-header ANSI C GUI library
#46> 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);
Or:
if (nk_button_label(&ctx, "button")) {
/* event handling */
}
Immediate mode GUIs are used in games, where you think in terms of drawing frames, each visible for a fraction of a second. When using such GUI, you usually "clear" it at the beginning of the frame, feed it with input from current frame, then build up the UI at the same time as you're drawing it[0].
So basically, you're in total control of the state; there is no persistent "input field", you recreate it each frame with a function call, and it's up to you whether or not it's meaningfully the same input field as it was the last frame.
--
[0] - most times, like in this case, "drawing" means you "build up" a list of display commands which then you feed to the renderer at the end - this lets an immediate mode GUI be independent of whatever graphics library you're using.
Re: Nuklear: A single-header ANSI C GUI library
#47Earlier quoted context omitted.
Thanks for the link. Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc. I'm still not convinced. I am convinced about a .c and .h -- that's how sqlite does it. Going to just a .h seems to prov…
> and confuses the implementation and interface Normally you have the implementation inside an "#ifdef IMPLEMENTATION" block, and the API interface (public structs and functions) outside of the implementation block, and all private functions inside the implementation block are defined as 'static' so they are not visible outside the special implementation source file. In the places where you include the header for nor…
OK I get that the big .h file is still logically separated into an .h and .c, like you say.
But what about preprocessing times? If you're including a library from many of your source files, then even if it always hits the #if 0 case, the preprocessor still has to parse the implementation. It matters for distributed compilation too -- more preprocessed bytes have to be sent over the network.
I'm sure there are cases where this overhead is negligible. But I'm just as sure there are some where it's not. Not caring about how much text is in your headers seems like a bad habit to get into. Build times are the main reason I don't use C and C++ more.
Re: Nuklear: A single-header ANSI C GUI library
#48Earlier quoted context omitted.
Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames . A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).
Point taken. Some games, though, could be accessible if not for the way the UI was implemented. For example, repackaged text adventures. I downloaded the Lost Treasures of Infocom app for iOS, and it was completely useless with VoiceOver. Presumably because the dev at Activision who was working on this packaging used the same kind of UI toolkit that they always use for games. The same goes for turn-based strategy gam…
I agree. It's good that you bring this up, and also great you provided some extra context about why you're doing this in another comment.