61–70 of 72 posts
Pretty crazy how this library blew up in the last 48 hours. Lol
Is this due to being posted here or am I missing something? As an aside, it would be nice if the title was or similar to: 'DearPyGui: A GPU Accelerated Python GUI Framework'
I can't find a clear explanation of "immediate mode" GUI creation (which this library enables) but it appears to be the sort of paradigm that pre-dated object-oriented and event-driven interaction handling that became the norm in the mid 90s (especially after the popularising of dev tools from Borland and Microsoft eg. Visual Basic etc), so I guess it is a formalisation of the procedural (?) methods from the era prec…
This library has functions such as add_button() that can be used to create a hierarchy of widgets. From this, I suspect that the library is not fully operating in immediate mode, but perhaps it uses some kind of mixed mode?
A couple small threads from recent weeks: https://news.ycombinator.com/item?id=24190011 https://news.ycombinator.com/item?id=24082524
Difference to pyimgui?
DearPyGui wraps Dear ImGui, provides a simulated traditional retained mode api, includes additional widgets and add-ons (plots, file dialogs, images, text editing widget, etc.), adds asyncronous support, addition items to the canvas, additional debug tools, etc.
Ultimately it tries to provide a complete package. Not a 1 to 1 wrapping.
I can't find a clear explanation of "immediate mode" GUI creation (which this library enables) but it appears to be the sort of paradigm that pre-dated object-oriented and event-driven interaction handling that became the norm in the mid 90s (especially after the popularising of dev tools from Borland and Microsoft eg. Visual Basic etc), so I guess it is a formalisation of the procedural (?) methods from the era prec…
Earlier quoted context omitted.
Correct. In order to tell if a button is clicked, you need to know whether it was clicked last frame, which means keeping around state. One difficulty with immediate-style GUIs is that it's difficult to tell whether two widgets are "the same". Dear ImGUI mostly uses a widget's label as its core identifier, which can cause issues if the button label changes. There's actually a lot more in common between React and ImGU…
This isn't true. All state you need to keep track of is purely the input state: e.g. whether a button is pressed, keys are pressed, etc. And very importantly, you also need to store the edges of the input signal. That is, you need to store whether left mouse has changed from not pressed to pressed this frame, and whether it has changed from pressed to not pressed. Then, the Button(...) call computes the hitbox of the…
This is correct. Windows (which includes things like popups and dialogs) have "state behind your back", but widgets generally don't - at least I've never seen it in the code. 99 % of the examples given by other commenters are not handled by hidden widget state, but by g.activeID. As someone pointed out, changing IDs in the middle of an interaction is problematic for that reason (not because imgui fails to find the widget in its hidden tree of widgets, which doesn't exist).