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

151–160 of 186 posts

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

#151

Post by printf_kek0 »

CamperBob2 wrote: post #147
printf_kek0 wrote: post #145

Earlier quoted context omitted.

I agree with the last part; should ask the Musl author(s) to substantiate this assertion. > [...] the standard should have included a keyword -- or the compiler authors a flag -- to allow people to opt in to these sorts of optimizations rather than requiring them to opt out. As an amateur Linux kernel hacker, I see hacks in the kernel that circumvent compiler bugs and unexpected behavior because of compiler defiance…

How exactly does a compiler generate "riskier" optimizations from a single-header as opposed to separate translation units? I fail to understand how after the pre-processing phase, this would be less safe. For instance, the optimizer might conclude that it's safe to either elide an inline function call or compile it very differently if it sees that you're referring to the same object in two separate parameters. If th…

Thank you. Please indulge me if you have time with two more questions:

1. In some libraries (SQLLite for instance, and libev too I think) the authors have a script that "amalgamates" all sources into a single translation unit.Their reasoning being that a compiler with full-visibility of the source can do global / interprodecural optimization that would not be possible otherwise. Is there any sense in this if it practical to do so for a small to moderate size library?

2. Please tell me what I should read so I can reach the same level of understanding that you have.

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

#153

Post by kqr »

angelsl wrote: post #132
to3m wrote: post #128

Earlier quoted context omitted.

https://github.com/tom-seddon/b2/blob/master/snmake.exe - standalone build of GNU Make 3.80. Has a couple of hacks in it to better support Windows-style paths with colons in it. I think this came from the SN Systems Playstation2 SDK. Thanks to the GPL, you can have it too. (I have no idea whether this will successfully run a C compiler for you on Windows, though. I mostly use it to run Makefiles with phony targets as…

Oh no, Make 3.80... Why not build a more recent version? This thing is 15 years old!

This sounds like something one should ask people who do not write portable makefiles, rather than porters of Make, which has been standardised for quite a while now.

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

#154

Post by yoklov »

pjmlp wrote: post #142
c-smile wrote: post #129

Earlier quoted context omitted.

Let's say you need zip lib functionality in your project. If it will be available as set of .h files you would include it by one line `#include zip.h` in your .c file. But libzip is made of .c files. How you would include it in your multiplatform project ? Visual Studio, XCode, etc... In general it would be great if C has `#include source "some.c"` feature. So you would add single file zip-lib.c that will contain `#i…

Easy, one links to the binary library. It really feels strange that young devs find it so hard to use a linker.

It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.

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

#155

Post by loup-vaillant »

mwcampbell wrote: post #117
loup-vaillant wrote: post #110

Earlier quoted context omitted.

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.

> IMO, it's much better than using a screen reader with a screen-oriented terminal application (ncurses or the like).

I suspected as much, which is why I was thinking purely REPL/batch stuff. On the REPL end, I was thinking programming languages (Python, Lua, Lisp, OCaml…), and stuff like gdb. On the batch end, I was thinking utilities like grep or awk, compilers, or ImageMagick. In other words, stuff that would work well with a printer.

I personally have a concrete use case in mind: file encryption, and password manager. I intend to write a first version for the command line, because it will be smaller and easier to write. Then I may do GUI versions. I was wondering to what extent the accessibility of the GUI version even matters, considering how simple the command line version would be.

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

#156

Post by random_upvoter »

billsix wrote: post #77
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 provi…

Yes, I did see the readme and I do remember thinking "so does this means it runs on Windows as well?". It's not unheard of for linux-specific projects to simply ignore the existence of Microsoft world.

So I cloned the repository and opened up nuklear.h. If this library supports Windows, then CERTAINLY this file has to include "Windows.h", somewhere, right? Uhm.. no, it does not. Bad sign, I thought.

So, still confused, I thought "so let's look into this folder called "example". I look into canvas.c and I notice "#include ". So I thought "Oh dear, this is gonna be a bother to compile on Windows, forget it". As luck would have it, I never looked into the folder called "demo".

So at that point I honestly believed that this library was only sort of "semi-supported" on Windows, as often happens with these kind of projects. You know, the usual "if you're a bit of a masochist and you're willing to muck around with mingw and download glib.tar.gz stuff, you may get this to work". The fact that the GUI has a definite linux look reinforced that impression.

What I'm saying is, all my confusion could have been solved by just one line in the readme explicitely stating "this builds on Microsoft Windows using Visual Studio and a direct X backend, etc...". A little bit of redundancy, it helps sometimes.

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

#157

Post by zxxon »

mwcampbell wrote: post #73
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…

>> 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.

This is also the reason why they are a pain in the butt to use, at least from the perspective of an IMGUI advocate. Those people usually have a game development background, so they're used writing bespoke solutions for everything.

Statelessness is a strength but also a big weakness, I doubt IMGUI will ever catch on its pure form. However, tools like React provide a fairly similar experience and they do produce object trees usable for screen readers. The missing piece here is something like a lightweight DOM for C/C++ projects.

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

#158

Post by IshKebab »

badsectoracula wrote: post #25
kzrdude wrote: post #15

Earlier quoted context omitted.

because dependency management and build systems are hard to get right and not standardized. It's a simple distribution model that works everywhere.

Yes, but why a single header file and not a pair of .c and .h files (personally this is what i do for my small libs)? With a single header file you'd need the user to put it in a specially designated "this is the implementation" .c file anyway. I can see it for C++ which supports placing code in a header as a language, but C requires jumping over awkward preprocessor hoops that can be avoided by using a .c file.

Header only means you don't have to modify your build system at all, and C++ build systems nearly all suck. A lot. (Only exceptions I've found are Meson and QBS.)

Though I agree a single header and single .c/cpp file is another good option and solves the compile time issues of throwing everything in the header.

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

#160

Post by JepZ »

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?

As Ken Thompson [1] (the one from Ken Thompson and Dennis Ritchie (Unix & C)) was one of the original authors of Go, I think it is safe to use the Golang Origins FAQ [2] as a source to answer this question.

> Dependency management is a big part of software development today but the “header files” of languages in the C tradition are antithetical to clean dependency analysis—and fast compilation.

That might be a reason to limit the use of header files to single file. In addition, I think that it is meant to make the adoption of the library easier.

[1]: https://en.wikipedia.org/wiki/Ken_Thompson [2]: https://golang.org/doc/faq#Origins

Post reply on HN