Live data from Hacker News

DearPyGui

github.com

31–40 of 72 posts

Re: DearPyGui

#31
post #15

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?

> From this, I suspect that the library is not fully operating in immediate mode, but perhaps it uses some kind of mixed mode?

From the linked readme: “DearPyGui provides a wrapping of DearImGui that provides a hybrid of a traditional retained mode GUI and Dear ImGui's immediate mode paradigm.”

Re: DearPyGui

#32
post #7

I'm curious if this is comparable to some of the other Python-based GUI frameworks out there: Tkinter, PyQT, Kivy, Toga.

Seems to be more comparable to PySimpleGUI, though on the surface it looks a little less simple and a little more featureful.

Re: DearPyGui

#33
post #2

How is it different from https://flutter.dev/desktop

> How is it different from https://flutter.dev/desktop

Well, it advertised itself as a simple way to provide a GUI for Python scripts.

I can think of lots of good uses for Flutter, but “a simple way to add a GUI to a Python script” isn't one of them.

So, I'm going to say they are entirely unrelated products with basically non-overlapping domains.

Re: DearPyGui

#35
post #6

Also adding this which I discovered last week, https://github.com/chriskiehl/Gooey

It'd be interesting to extend this to handle pipelines, maybe by using some sort of thing where you drag from the output field(s) of a utility to an input field of another, causing them somehow to be fused.

Re: DearPyGui

#36
post #8

Oh, I love Dear Imgui -- it's very simple to use and has a nice... "engineering"/scientific aesthetic. Good to hear it's been ported to python. If you're looking for an end-user product, this may not give you the control you're looking for. But if you're looking for a dead-simple way to create a quick GUI for a side project, this is perfect.

What's your recommendation for a Python-engineered end-user product?

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

Re: DearPyGui

#37
post #14
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…

> 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 many games it does make sense to update th GUI on every frame. E.g. if you have a minimap you will need to update that every frame during which the player is moving.

Updating every frame also solves the issue of the GUI updates not being synchronized with screen refreshes (v-sync). You could do something like use event driven programming to draw the GUI to a buffer off screen, and layer that on top of the main render. But that's probably about as intensive as drawing the UI, and more memory intensive.

Re: DearPyGui

#38

Earlier quoted context omitted.

What's your recommendation for a Python-engineered end-user product?

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?

Re: DearPyGui

#39
post #8

Oh, I love Dear Imgui -- it's very simple to use and has a nice... "engineering"/scientific aesthetic. Good to hear it's been ported to python. If you're looking for an end-user product, this may not give you the control you're looking for. But if you're looking for a dead-simple way to create a quick GUI for a side project, this is perfect.

The underlying "imgui" https://github.com/ocornut/imgui project:

From the github page - EDIT: Read the bindings / frameworks page too, https://github.com/ocornut/imgui/wiki/Bindings It's still c++ like.

"""

Officially maintained bindings (in repository):

Renderers: DirectX9, DirectX10, DirectX11, DirectX12, OpenGL (legacy), OpenGL3/ES/ES2 (modern), Vulkan, Metal.

Platforms: GLFW, SDL2, Win32, Glut, OSX.

Frameworks: Emscripten, Allegro5, Marmalade.

Third-party bindings (see Bindings page):

Languages: C, C# and: Beef, ChaiScript, D, Go, Haskell, Haxe/hxcpp, Java, JavaScript, Julia, Kotlin, Lua, Odin, Pascal, PureBasic, Python, Ruby, Rust, Swift...

Frameworks: AGS/Adventure Game Studio, Amethyst, bsf, Cinder, Cocos2d-x, Diligent Engine, Flexium, GML/Game Maker Studio2, Godot, GTK3+OpenGL3, Irrlicht Engine, LÖVE+LUA, Magnum, NanoRT, Nim Game Lib, Ogre, openFrameworks, OSG/OpenSceneGraph, Orx, Photoshop, px_render, Qt/QtDirect3D, SFML, Sokol, Unity, Unreal Engine 4, vtk, Win32 GDI, WxWidgets.

Note that C bindings (cimgui) are auto-generated, you can use its json/lua output to generate bindings for other languages.

"""

Re: DearPyGui

#40

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?

I've had good luck with https://www.pyinstaller.org/ and Qt in python.
Post reply on HN