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

91–100 of 186 posts

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

#91

Post by moefh »

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.

> Even if you had a gigabyte of text in an #if 0, that's only about 2 more seconds on the compile

Are you sure your implementation is correct? How does it handle this:

    #if 0
    "\
    #endif \
    "
    #endif
I'm not saying gcc's and clang's preprocessors are not really fast, but preprocessing is trickier than most people expect. In particular (as you can see from my example), while skipping over an "#if 0" you still have to split the source into tokens and discard the tokens.

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

#92

Post by Myrmornis »

mwcampbell wrote: post #88
Myrmornis wrote: post #86

Earlier quoted context omitted.

I think your comments here and in the other thread are thoughtful and well-intentioned and are in general the right comments to make. However, I must admit that the incidents where UC Berkeley and other universities removed public access to many thousands of hours of videos of online undergraduate lectures severely reduced the extent of my sympathy for accessibility advocates. It sounds like a no-brainer to be sympat…

What Berkeley did with its lectures is not the fault of accessibility advocates. I'll just point you to this comment from a blind friend: https://news.ycombinator.com/item?id=14580342

I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy.

I'm sorry but I disagree strongly with your blind friend. E.g.

> this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago.

They are just videos of a lecture. They can be put on the internet.

EDIT: That sounds like I don't understand his point. I think I do: we've had decades to get used to the idea that content should/must be accessible, and of all institutions, a large public university should certainly be doing that now, in 2017.

However, I just can't make myself accept it. They are just videos of a lecture. They can be put on the internet. Certainly they would be better if accessible, but once up it is vandalism to take them down.

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

#93

Post by jstimpfle »

billsix wrote: post #80
jstimpfle wrote: post #74

Earlier quoted context omitted.

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

> 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 before, and I was thinking it had quite a few hacks to find the objects from last frame. Lots of best effort guessing and workaround schemes to keep the API calls "concise".

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

#94

Post by mwcampbell »

Myrmornis wrote: post #92
mwcampbell wrote: post #88

Earlier quoted context omitted.

What Berkeley did with its lectures is not the fault of accessibility advocates. I'll just point you to this comment from a blind friend: https://news.ycombinator.com/item?id=14580342

I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy. I'm sorry but I disagree strongly with your blind friend. E.g. > this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago. They are just videos of a lecture. They can be put on t…

I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made accessible. What we all wanted, of course, was for Berkeley to make the lectures accessible, not remove them. The fact that Berkeley removed them is Berkeley's fault, not ours. Your problem should be with Berkeley, not with us.

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

#95

Post by loup-vaillant »

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

Earlier quoted context omitted.

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.

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.

> But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools.

No you don't: just act as if you've written the damn thing yourself. Your tools don't have to know. How being multiplatform changes anything?

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

#96

Post by Myrmornis »

mwcampbell wrote: post #94
Myrmornis wrote: post #92

Earlier quoted context omitted.

I am not sure what you mean by "fault" but it was certainly the result of accessibility advocacy. I'm sorry but I disagree strongly with your blind friend. E.g. > this continuing trope of "OMG I didn't realize we needed to make our content accessible! Woe, woe are we!" passed through the realm of disingenuous and into that of pure bullshit a long, long time ago. They are just videos of a lecture. They can be put on t…

I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made ac…

I'm just going to be honest and admit that my instinct is that demanding accessibility is too high a barrier. I want to live in a world where a lecturer is about to start a lecture and someone in the class says "hey can I record this it would be cool for others to see" and the lecturer says "sure!" and the simple phone-captured video goes up on the internet for ever.

Now if someone can make technology to make that accessible, post-hoc, awesome. And if someone can make it easy for the content to be born accessible, even better! But I do not agree with making accessibility required.

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

#97

Post by mwcampbell »

Myrmornis wrote: post #96
mwcampbell wrote: post #94

Earlier quoted context omitted.

I think I understand why the outcome in this case frustrates you. Taking down the videos didn't do anyone any good, except that it was the easiest way out for Berkeley. Now, nobody has access to that information. So, one might argue that it's stupid that Berkeley was required by law to remove inaccessible content. But if that requirement wasn't there, the law would have no teeth, and other content wouldn't be made ac…

I'm just going to be honest and admit that my instinct is that demanding accessibility is too high a barrier. I want to live in a world where a lecturer is about to start a lecture and someone in the class says "hey can I record this it would be cool for others to see" and the lecturer says "sure!" and the simple phone-captured video goes up on the internet for ever. Now if someone can make technology to make that ac…

I understand your opinion, but I think I must still disagree with it. I do think accessibility should be required, unless it's just not possible in some situation. And content should be, as you said, born accessible.

And not just accessibility for blind people, of course. And here I have to be honest and admit that I haven't lived up to this ideal myself. Several months ago, I gave a presentation to a local Meetup group for software developers on making software accessible to blind people. It's on YouTube. But I haven't yet had it captioned so a deaf person can benefit from it. Nobody's coming after me with a lawsuit in hand. But now that I've thought of this, I should get that video captioned.

Or maybe the presentation or lecture itself is an archaic way to share information. You can see it in the word "lecture". It comes from reading, as in reading out loud. But the people who attend today's lectures can read for themselves. Maybe the best way for content to be born accessible is just to stick to electronic text, that everyone can read in their own way and at their own pace.

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

#98

Post by billsix »

jstimpfle wrote: post #93
billsix wrote: post #80

Earlier quoted context omitted.

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…

> 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 be to use.

I'm not quite sure what you're advocating to do, but if you make a better graphical user interface framework than those other two projects, then I can't wait to see it.

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

#100

Post by v_lisivka »

TeMPOraL wrote: post #34
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…

> 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 That part was justified by deploying libraries for Windows. Going for one file only was justified by this: "You don't need to zip or tar the files up, you don't have to remember to attach two…

For some reason, problems with DLL libraries are called as "DLL hell", not "SO hell". ;-)

If your software needs library foo.so.x while other application needs library foo.so.y, just put both into /usr/lib. Problem solved.

Post reply on HN