Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DearPyGui

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: DearPyGui

#41

Post by mixmastamyk »

DizzyDoo wrote: post #38
formerly_proven wrote: post #36

Earlier quoted context omitted.

Native, if cross-plattform then Qt or wx (only "old" widgets).

A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?

Pretty much the same, though it was never that difficult. There is also PyOxidizer, and zipapp is an option for some.

Re: DearPyGui

#42

Post by formerly_proven »

DizzyDoo wrote: post #38
formerly_proven wrote: post #36

Earlier quoted context omitted.

Native, if cross-plattform then Qt or wx (only "old" widgets).

A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?

That's still the way to go, and it's still fiddly and always requires manual tweaking until it works. Especially on Linux. Deploying binaries on Linux is just always a hassle, and never works "everywhere"...

Re: DearPyGui

#43

Post by Jasper_ »

flohofwoe wrote: post #24
ratww wrote: post #12

Earlier quoted context omitted.

Immediate Mode GUIs are just GUIs that are instanced and drawn immediately during a single frame. There's no need to persist any object or structure because the whole screen will be cleaned and redrawn in the next frame. Immediate mode is popular in video games because in most games the screen is re-rendered on each frame. This is in opposition from retained-mode, where things are re-rendered only when necessary, lik…

> There's no need to persist any object or structure because This isn't quite correct, at least for the library internals. Dear ImGui does persist UI state between frames, the "immediate mode" term only describes how the API looks like to the user, not how the library behind the API is implemented. The user code doesn't need to keep "widget handles" around, and there is no "event handler code" that is called asynchro…

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 ImGUI than you might think, in terms of "state reconciliation". The difference is that React is diffing to apply itself to a retained model, while ImGUI retains the state behind your back.

Re: DearPyGui

#44

Post by cma »

corysama wrote: post #28
diath wrote: post #14

Earlier quoted context omitted.

> Immediate mode is popular in video games because in most games the screen is re-rendered on each frame. That makes no sense though because while you still need to re-render each frame, you do not necessarily have to waste rendering time on GUI each frame when GUIs are mostly static, why not just render the interface to a framebuffer and then simply draw that when composing a frame and only re-draw the framebuffer w…

In games it is far more important that performance be consistent than that it is be better on average . Spikes in performance mean hitches in the presentation. Hitches are terrible user experience. Better to run a solid 30 fps 100.0% of the time than to run 60 99% of the time and hitch every 2 seconds.

Hitches are still bad, but consistency is less needed with variable refresh rate monitors.

Also, battery life/power usage is an important factor that can push you away from focusing only on consistency.

Re: DearPyGui

#45

Post by _frkl »

DizzyDoo wrote: post #38
formerly_proven wrote: post #36

Earlier quoted context omitted.

Native, if cross-plattform then Qt or wx (only "old" widgets).

A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?

This is a fairly comprehensive build system for gui apps in python, I think: https://build-system.fman.io/

Re: DearPyGui

#46

Post by nightcracker »

Jasper_ wrote: post #43
flohofwoe wrote: post #24

Earlier quoted context omitted.

> There's no need to persist any object or structure because This isn't quite correct, at least for the library internals. Dear ImGui does persist UI state between frames, the "immediate mode" term only describes how the API looks like to the user, not how the library behind the API is implemented. The user code doesn't need to keep "widget handles" around, and there is no "event handler code" that is called asynchro…

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 button, checks whether the left mouse button has changed from 'not pressed' to 'pressed' this frame, and if yes, whether the mouse coordinates are inside the hitbox. If yes, it returns True, else it returns False.

No widget state needs to be kept.

Re: DearPyGui

#47

Post by smaddox »

mellosouls wrote: post #9

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…

As far as I can piece together, Casey Muratori first described the approach in an early YouTube video in 2005: https://youtu.be/Z1qyvQsjK5Y

The basic approach certainly existed far earlier, though. Early "graphical" command line applications, for example, most likely all took an immediate mode approach. It's just that no one thought it was worth making the distinction until after living through the hell that is retained mode GUI programming.

In a way, React (along with other vdom-based GUI frameworks) is another rediscovery of immediate mode GUI techniques, but with more of a functional (reactive) programming influence.

Re: DearPyGui

#48

Post by smaddox »

cma wrote: post #44
corysama wrote: post #28

Earlier quoted context omitted.

In games it is far more important that performance be consistent than that it is be better on average . Spikes in performance mean hitches in the presentation. Hitches are terrible user experience. Better to run a solid 30 fps 100.0% of the time than to run 60 99% of the time and hitch every 2 seconds.

Hitches are still bad, but consistency is less needed with variable refresh rate monitors. Also, battery life/power usage is an important factor that can push you away from focusing only on consistency.

Variable refresh rate monitors don't solve hitching due to variable computation. In order to render an animation smoothly, you have to know precisely when a frame will be displayed ahead of time, so that you can render the simulation precisely at that point.

Re: DearPyGui

#49

Post by Jasper_ »

nightcracker wrote: post #46
Jasper_ wrote: post #43

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…

There's a bit more subtlety than that. If I press down on a button, then move my mouse off of it, it will be deselected. This is normal and not too hard to implement your model. But, if I keep my mouse button held down, and drag back on, it will become re-highlighted, and it will go through. Note that only the button I originally clicked on will have this behavior. I just tested this right now in the ImGUI demo, so clearly per-widget state is tracked (or at least which "widget" is the one that has the mouse's active state): https://github.com/ocornut/imgui/#demo

If you think this is obscure, try implementing a slider widget any other way. You need a way to keep track of which slider you were dragging, even when the mouse cursor leaves to another.

Re: DearPyGui

#50

Post by nightcracker »

Jasper_ wrote: post #49
nightcracker wrote: post #46

Earlier quoted context omitted.

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…

There's a bit more subtlety than that. If I press down on a button, then move my mouse off of it, it will be deselected. This is normal and not too hard to implement your model. But, if I keep my mouse button held down, and drag back on, it will become re-highlighted, and it will go through. Note that only the button I originally clicked on will have this behavior. I just tested this right now in the ImGUI demo, so c…

This is solved by the exact same state I mentioned earlier.

The only thing I need to make explicit is that you store the mouse coordinates of each event type with that event, for later retrieval. E.g. `events['mouse_down_edge']` stores a tuple `(frame_nr, coords)`.

Then you know that we are dragging this slider if the mouse is held down, and its initial down edge in the signal was generated while hovering over this slider.

---

For what it's worth, I know that (some parts of) dear ImGUI are not implemented in the above way, and instead do keep track of some widget state with labels and unique ids. People however heavily overestimate to what extent this is necessary.

Post reply on HN