181–186 of 186 posts
Earlier quoted context omitted.
> any executable code appearing in a header file might end up existing in multiple copies throughout the executable that's why the keyword "inline" exists.
'Inline' does not prevent duplication of the generated code (in fact, it forces it).
Earlier quoted context omitted.
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.
However I have better things to do than try to figure out how to build GNUstuff myself on Windows.
Earlier quoted context omitted.
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 pass…
Before I used immediate mode GUIs, I was familiar with using Qt, wx, and gtk. Never did X windows. So I never handled events directly, just indirectly programmed what would happen upon the event occuring.
I had been under the likely incorrect assumption that those frameworks, in order to correctly associate say a mouse click to a button, had a mapping of the previous frame's screen-space coordinates of all widgets, and when a click happened, they associated the click with the previously drawn widget. Because that is what was on the screen when the mouse was clicked.
Immediate mode GUIs baffled me. How could the drawing of a button, which has not yet been flushed to the monitor, return true or false depending upon whether or not it was clicked? The button is not yet on the monitor!!! After thinking about it for 10 minutes, buttons don't fly all over the screen. Whatever the bounding box for the button for this frame is likely the bounding box it had last frame. So the association is easy, assuming the imgui framework can keep track of object identity across frames.
Perhaps, I am just ignorant of how qt, gtk, and wx, actually work.
Earlier quoted context omitted.
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...
Reimplementing parts of the standard library is important for applications where you don't neccessarily have access to a standards-compliant libc (read Windows), or if you have need custom malloc/free implementations. Similar techniques are used in automake and similar build generators to provide non-standard libc function implementations. precompiled headers can help with the fact that good portions of the header wi…
- AssortedWidgets: https://shi-yan.github.io/AssortedWidgets/
- Dear ImGUI: https://pbrfrat.com/post/imgui_in_browser.html