As a small criticism, looking at the project page I get no clue whether this library works on Microsoft Windows.
Yes you have a win32 and direct x 9 and 11 backend...
Nuklear: A single-header ANSI C GUI library
131–140 of 186 posts
Re: Nuklear: A single-header ANSI C GUI library
#132Earlier quoted context omitted.
Errr, I actually have to spend 5 minutes googling how to install make on Windows, then getting mingw and hating myself. So no, no it's really not that simple in general.
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!
Re: Nuklear: A single-header ANSI C GUI library
#133Earlier 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…
> 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?
A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both of which are usually provided to the system on a per-frame basis. I've not used Nuklear, but this is how dear imgui works. If the GUI system knows where you are clicking, and must know the position of the button it's drawing (in order to render it), then it should be able to tell if it's being pressed.
Re: Nuklear: A single-header ANSI C GUI library
#134Earlier 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!
Good idea! Let me know when you’ve done it... I could do with an updated copy.
Re: Nuklear: A single-header ANSI C GUI library
#135Earlier 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…
> 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? A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both…
Nice, but what about a double-click, long press, or drag?
Is it just about detecting whether an input button is currently down, or is there some way to handle a gesture happening over time?
Re: Nuklear: A single-header ANSI C GUI library
#136Earlier quoted context omitted.
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.
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…
I am not comparing many-c-files (like your libzip example) with single header, i am comparing the single header with a pair of c/h files.
Re: Nuklear: A single-header ANSI C GUI library
#137Earlier quoted context omitted.
> 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? A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both…
Nice, but what about a double-click, long press, or drag? Is it just about detecting whether an input button is currently down, or is there some way to handle a gesture happening over time?
At least in dear imgui, the input information is provided every frame, so the system can track it over time. If you want to see if there was a double click, then you can call "IsMouseDoubleClicked", for example.
Re: Nuklear: A single-header ANSI C GUI library
#138Earlier 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…
> 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? A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both…
I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument.
Buttons don't fly around the screen over time. If a user clicked on the screen 1.0/144 seconds ago (assuming a 144 htz monitor), the user likely clicked on the button which is about to be redrawn.
Re: Nuklear: A single-header ANSI C GUI library
#139Earlier quoted context omitted.
> 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? A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both…
I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument. Buttons don't fly around the screen over time. If a user clicked on the screen 1.0/144 seconds ago (assuming a 144 htz monitor), the user likely clicked on the button which is about to be redrawn.
I guess I don't understand why this would be true:
> The imgui framework handles the previous frames events when drawing the current frame.
I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).
Re: Nuklear: A single-header ANSI C GUI library
#140I 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?
Developers that don't want to bother how to properly use a linker.