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

111–120 of 186 posts

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

#111

Post by loup-vaillant »

ptx wrote: post #30
bastijn wrote: post #24

Earlier quoted context omitted.

Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…

> not every next important application will be used by blind people or people with disabilities If this application is important to people in general, it wouldn't stop being important just because you happen to be blind or otherwise disabled. If everyone uses a particular walled-garden service for some daily task, blind people need to use it too, just the same as everyone else.

There are a couple domains for which I'm pretty sure sight is required. Photoshop for instance. Is there any way this program could be made accessible?

For all the others, I wonder if a command line interface wouldn't just be better—sometimes not just for the blind.

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

#112

Post by naivete »

kaslai wrote: post #85
chubot wrote: post #47

Earlier quoted context omitted.

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 w…

The C preprocessor is the least of your worries with regard to compile times. Parsing a #if 0 can be done almost as quickly as a memcmp operation. Even my naive implementation can process an #if 0 at around 600 MBps. Even if you had a gigabyte of text in an #if 0, that's only about 2 more seconds on the compile, provided your disk can manage the throughput.

Is your naive preprocessor implementation complete and standards compatible C99? Or just some bastardization of it? If not the 600 MBps bench is as good as useless.

What's the C preprocessor speed of GCC/Clang/MSVC? Any benches?

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

#113

Post by rixed »

flohofwoe wrote: post #35
svdree wrote: post #27

Earlier quoted context omitted.

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files. The convenience of only having to include a single header is nice for quick weekend p…

Some advantages of header-only vs .h/.c pair: - you can build simple tools contained in a single .c file, and you dont't need a build system for this (e.g. just call "cc tool.c -o tool" instead of mucking around with Makefiles or cmake) - the library can be configured with macros before including the implementation (e.g. provide your own malloc, assert, etc...), with the implementation in a .c file, these config macr…

Make is so simple that it can actually build you single file project without a makefile with less characters to type:

make tool

Et voilà.

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

#114

Post by naivete »

kilpikaarna wrote: post #22
zevv wrote: post #13

I 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?

Especially when that single header is over 13k lines and reimplements half the standard library. This looks pretty cool and I have an idea for an OpenGL project that needs a GUI, so I'll probably try it out at some point, but it doesn't really seem as lean and straightforward as the blurb implies...

There isn't really that much unnecessary stuff in there. It's more like 20k LoC but half of it is comments. And if included as a header most of it will get stripped away by the preprocessor.

Just for context, in C++ including std::string (after preprocessing) will pull in 25k LoC, std::vector around 20k.

Programming in C++ by the book will average around 35k LoC per every compilation unit. And it will compile significantly slower than C code.

Having that in mind, and considering that Nuklear doesn't pull in any dependencies, not even C stdlib parts. I think author has done a good job at being lean and fairly straightforward.

UI libs are usually a huge dependency and a hairy mess. This is not really the case. It's just one ~1mb 20k line header file.

There is some overhead on preprocessing over having a .c/.h combo, but that's it.

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

#115

Post by naivete »

wott wrote: post #89
zevv wrote: post #13

I 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 have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. I mean, we've been nicely organising our sources in files, modules and libraries for 30 years, and that's been fine: very easy, logical and giving us many benefits (such as quick partial builds, splitting different operations, isolating problems f…

What are you talking about, C doesn't have a concept of a module or a library in the first place.

Nothing about C is easy or logical. C only makes sense in 1965 on PDP7. All these hacks just work around the inherent shittyness of C/C++.

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

#116

Post by jstimpfle »

billsix wrote: post #98
jstimpfle wrote: post #93

Earlier quoted context omitted.

> 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. So why not allocate the necessary structures on the caller-side, and hand them as arguments to update and render calls? I think that's cleaner. It's the way I've started going forward for my own experiments. I briefly looked into Dear Imgui b…

I think overall you and I agree quite a bit. But as far as I can tell, nuklear is designed to be simple to program the implementation, and simple to program against, at the cost of some features. https://github.com/vurtun/nuklear/issues/50 Dear imgui may have some hacks as you mention to achieve features such as using tab to switch the active component, (I've never looked at the source), but it's still simple as can…

Always happy to find people to connect to and talk about how to actually _make_ infrastructure instead of only using it. (Maybe it's not brainy or sexy enough?)

I've only begun making some UI elements. At the moment I have a keyboard-driven menu, and a slider box and an unused button with misplaced caption that react to mouse clicks. There's a lot more infrastructure I've experimented with and the UI just barely works -- but I'll soon need and work on more 2D UI functionality. One problem is that I'm not sure how to structure 2D rendering, having to deal with modern OpenGL. But I need this experience to inform my UI architecture. I will probably study vurtun a bit.

So if you're interested check back in two weeks (and I'm happy to receive feedback).

https://github.com/jstimpfle/learn-opengl/blob/master/ui.c

https://github.com/jstimpfle/learn-opengl/blob/master/meshvi...

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

#117

Post by mwcampbell »

loup-vaillant wrote: post #110
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

Let's say I'm implementing an application blind users should be able to use (not an FPS game or drawing program). Aren't GUIs a pain in the butt even when properly implemented with the right accessibility hooks? How about writing a command line version of the program? Wouldn't that be much more accessible? I'm not even thinking ncurses, I'm thinking about a REPL, or even non-interactive like grep or awk.

Blind programmers and sysadmins sometimes prefer command-line tools. But most blind people are now thoroughly accustomed to GUIs. An accessible GUI can be very usable. IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like). If you're skeptical, I can put together a little demo of one or two use cases on Windows and/or the iPhone.

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

#118

Post by gameswithgo »

chubot wrote: post #31
svdree wrote: post #27

Earlier quoted context omitted.

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files. The convenience of only having to include a single header is nice for quick weekend p…

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…

I don't understand why anyone cares. you grab the .h file and call "load a jpeg"/"draw a button" or you grab two files and call "load a jpeg"/"draw a button"

Are we bikeshedding about this?

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

#120

Post by CamperBob2 »

zevv wrote: post #13

I 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 think the real reason for this stance is that it imposes a sense of discipline that wouldn't otherwise be there. When you write a library like this one, you're always tempted to overengineer it... maybe it needs to render .PDFs (or render to them)? Wouldn't it be nice if it supported various OS clipboards? How about supporting both OpenGL and DirectWhatever and that homebrew software renderer that you wrote a few years ago? And wow, it sucks to build complex interfaces by aggregating C function calls. Lua support would only take a few more KLOCs, right? ...

And before you know it, you're reinvented Qt. NTTAWWT, I guess, but if you set out to build a lightweight set of GUI controls for a specific purpose, you probably had a different goal in mind, and that's not the way to accomplish it.

In my own work I frequently include stb libraries in separate .c(pp) files that provide a somewhat higher-level C or C++ interface to the features I need, which are then linked in the traditional way with .obj files and minimal headers. This approach works well, maintaining encapsulation and keeping compile times down while avoiding dragging in a ton of random dependencies.

Post reply on HN