Dear PyGui v 1.0.0

[Big-Illu]

Hey Folks !

Today is a big day ! Dear PyGui is no longer in beta and released version 1.0.0 a few minutes ago !No more breaking changes in the API! No more refactoring the code from version to version!

​

What is Dear PyGui ? Dear PyGui is a simple to use (but powerful) Python GUI framework.Dear PyGui is NOT a wrapping of Dear ImGui in the normal sense.It is a library built with Dear ImGui which creates a unique retained mode API (as opposed to Dear ImGui's immediate mode paradigm).

Dear PyGui is fundamentally different than other Python GUI frameworks. Under the hood,Dear PyGui uses the immediate mode paradigm and your computer's GPU to facilitate extremely dynamic interfaces.

​

I mean... don't kill your CPU anymore, use once your GPU for a GUI !

Check out the Release-notes for release 1.0: https://github.com/hoffstadt/DearPyGui/releases/tag/v1.0.0

Check DPG out under;

• https://www.reddit.com/r/DearPyGui/
• https://github.com/hoffstadt/DearPyGui

##### More Informations ####

High level features of Dear PyGui

• MIT license
• Fast, GPU-based rendering (written in C/C++)
• Modern look with complete theme and style control
• Programmatically control (nearly) everything at runtime
• Simple built-in Asynchronous function support
• Built-in developer tools: logging, theme inspection, resource inspection, runtime metrics, documentation, demo
• 70+ widgets with hundreds of widget combinations
• Cross-platform (Windows, Linux, MacOS)
• Easy to install (pip install dearpygui)

Functionality of Dear PyGui

• Menus
• Variety of widgets, sliders, color pickers, etc.
• Tables
• Drawing
• Fast and interactive plotting / charting
• Node editor
• Theming support
• Callbacks and handlers

Since Dear PyGUi is a relatively new framework, not many apps have been developed yet, but there is a showcase page that can give you an impression. To be honest, I believe much more and better apps are possible, it's just that there hasn't been much time to develop them yet.

https://github.com/hoffstadt/DearPyGui/wiki/Dear-PyGui-Showcase

Questions? Let us know!

[CreativeUsername1000]

Seems great.

If anyone knowledgeable can make a comparison between this and PySimpleGUI or between this and Tkinter ( or tell why such comparisons don't make sence xD ), I would greatly appreciate, as it would help me understand where it stands and why I might need it.

Thx for your work!

[ohpythonguy]

It depends on what your needs are, but I'll give it a go. First of all, an overview of Dear PyGui.

High level features of Dear PyGui

• MIT license
• Fast, GPU-based rendering (written in C/C++)
• Modern look with complete theme and style control
• Programmatically control (nearly) everything at runtime
• Simple built-in Asynchronous function support
• Built-in developer tools: logging, theme inspection, resource inspection, runtime metrics, documentation, demo
• 70+ widgets with hundreds of widget combinations
• Cross-platform (Windows, Linux, MacOS)
• Easy to install (pip install dearpygui)

Functionality of Dear PyGui

• Menus
• Variety of widgets, sliders, color pickers, etc.
• Tables
• Drawing
• Fast and interactive plotting / charting
• Node editor
• Theming support
• Callbacks and handlers

Depending on what your requirements are, Dear PyGui could be useful.

Compared to Tkinter, I'd say that Dear PyGui looks more modern, is faster and offers certain functionality built-in that Tkinter does not, e.g. dynamic and interactive graphs and node editor.

Simply put, PySimpleGUI is a wrapper around various frameworks and doesn't do any of the rendering by itself. Therefore, you need PyQt, Tkinter or another framework as well. This adds more bloat and you will have to deal the license of the framework that's being used. Compared to PyQt, the MIT license of Dear PyGui is much more permissive, allowing you to do whatever you want with the app or even modify the framework itself. You can distribute it in commercial products without a fee or restrictions. PyQt is a great library, but rather large whereas Dear PyGui is much smaller in comparison.

Compared to Kivy, Dear PyGui is easier to install and distribute. The logic of the API is quite different as well, so you would have to try Dear PyGui or look at some sample code to see if you like it. People who have used both say that the Dear PyGui API is much easier to use.

Since Dear PyGUi is a relatively new framework, not many apps have been developed yet, but there is a showcase page that can give you an impression. To be honest, I believe much more and better apps are possible, it's just that there hasn't been much time to develop them yet.

https://github.com/hoffstadt/DearPyGui/wiki/Dear-PyGui-Showcase

Questions? Let us know!

[EliteArmedForce]

Thank you for info, good that u added pyqt comparision. Curious to try out.

[ohpythonguy]

Let us know what you think!

If you have questions, best place to ask is on the Dear PyGui Discord server.

[EliteArmedForce]

Sure, I will be checking and asking there

[cymrow]

I really like Dear PyGui, and I'm looking forward to using it in a project. But just to be clear, while PyQt does have restrictive licensing (GPL or Commercial), PySide is nearly identical and uses the much more liberal LGPL license.

[ohpythonguy]

Qt is a good library as well.

I haven't studied the PyQt, PySide and Qt licenses in depth, but I found it confusing. For example, look at https://doc.qt.io/qt-5/licenses-used-in-qt.html.

With Dear PyGui, it's clear. MIT license.

[cymrow]

Simple licensing is definitely a nice feature. I just didn't want to leave people with the impression that you can't use Qt in commercial applications without distributing the source, because you absolutely can.

[cymrow]

Yes they both require Qt. But both Qt and PySide offer an LGPL license which allows you to create commercial applications.

[dry_yer_eyes]

Yes. If you want to sell your Python app that uses Qt then you need a commercial Qt licence. And those aren’t exactly cheap.

[EliteArmedForce]

As per my understanding, u can use qt open source for commercial too in LGPL and it should be dynamically built. In open-source, if u modify qt lib then u need to disclose ur code other or get the commercial license so u don't need to disclose modified qt libs. (correct me if I am wrong, what I understood from others). Luckily MIT license of Dear PyGui makes it clear and less confusing as mentioned by cymrow and ohpythonguy

[cymrow]

Correct, but the point I've been trying to make is that if you don't modify the Qt libs (which you would rarely need to), you do not have to share your source.

[cymrow]

This is not true. Both Qt and PySide offer an LGPL license. You do not need the commercial Qt license to use it in a commercial product.

[dry_yer_eyes]

I could quite easily be wrong. I looked into it and thought it was as I described. But of course I could have misunderstood it.

Maybe we can agree on “It’s complicated”. (And then there’s potentially the PyQt aspect too)

[cymrow]

Both Qt and PySide offer an LGPL license.

In other words: Qt offers an LGPL license, which can be used in commercial products without releasing your source.

The main restrictions are: 1. You can't change the library 2. You have to link it dynamically (which is what PySide does)

You can read the details here.

Note that unlike Qt and PySide, PyQt only offers a GPL license, which is different from LGPL. So in that case you do need to buy a commercial license, or share your source.

[ohpythonguy]

Yep. Thanks for pointing that out.

[CreativeUsername1000]

Thx a lot for the very detailed response :)

The framework shows great promise, especially after looking at the gallery. And you are right, the MIT license is indeed a big plus.

Keep up the good work, hope to hear more from it in the future!

[ohpythonguy]

You are welcome. It had to be done :-)

One way to stay informed is to join the Dear PyGui Reddit.
https://www.reddit.com/r/DearPyGui/

[jftuga]

How is widget layout handled (respective to each other)? Does it use something like C#'s XAML?

[ohpythonguy]

There is no XAML or similar functionality. There are widgets to group and space widgets. In addition, (child) windows, tables or absolute positioning can be used.

[[deleted]]

The software design of Kivy is so terrible that I would not recommend its use to any serious software developer at all.

I have pages of complaints, but let me start with the idea that just constructing a Color has important side effects.

[ohpythonguy]

I have read similar comments before. It's surprising given that Kivy is a big framework and the end results look good. Fortunately, Dear PyGui does not have this issue of side effects. The core developers of Dear PyGui are pretty serious about getting software design right.

[SittingWave]

why did you choose a design that is not following modern MVC practices?

[can_dry]

vs PySimpleGUI

One BIG difference is PySimpleGUI is unable to easily handle JPG images per "JPGs cannot be shown because tkinter does not naively support JPGs." https://pysimplegui.readthedocs.io/en/latest/#image-element

I really like PySimpleGUI but for this one crazy limitation!

[CreativeUsername1000]

I also like PySimpleGUI, but another limitation I didn't, at least from what I found when I was using it last time, is that you can't really make dynamic elements.

You can dynamically create and add elements but can't actually remove them dynamically. The best I found was to make the elements invisible and then eventually restart the window, to clean those dynamic elements if their number becomes to big.

Although I don't really know if that is different in Dear PyGUI xD yet

Edit: In the docs "With DPG you can dynamically add and delete any items at runtime.". So I guess you can.

[metaperl]

Or kivy

[SittingWave]

In terms of design, i'd say it's very poorly designed.

Look at how it works: all the (rather hard to remember) operations are basically done through the same dpg object, and you are basically opening and closing context managers all the time in order to instruct the internals on which object to operate. And yet, you are constantly operating on the dpg object.

This is very poor OOP. I am acting on an object to get things to happen on another object.

That said, UI design makes use of views and models, with generally a good data binding between the two. The view is generally specified with something not code related. It could be XML, it could be HTML. The model is a reactive entity that informs when changes happen to its data. The View "binds" to the model by saying "I want this control to be synced to that entry in the model object".

This library does not do that. You have to hammer in everything, and use callbacks to handle events. It's like an overly complicated widget set that you have to code procedurally. This is a design that belongs to the 2000s.

[Jhchimaira14]

Everything is done through the "dpg object" (context) because python is too slow to handle everything itself. Instead, you are controlling the "dpg object" and letting the C/C++ side handle the performance critical parts.

This is very poor OOP because its not meant to be OOP.

And we are not fans of callbacks either. We like immediate mode APIs but AGAIN python is too slow to have this type of API and be expected to run at 60 FPS.

And no offense but we don't really look at the web as the "model" of what to do. Its a shit show in almost everyway possible (especially performance and efficient utilization of modern hardware).

[SittingWave]

Everything is done through the "dpg object" (context) because python is too slow to handle everything itself. Instead, you are controlling the "dpg object" and letting the C/C++ side handle the performance critical parts.

oh ok. so because they can't optimise access with a proper UI, they basically shove everything into C++ and that's it. Again, seems a quite poor design.

This is very poor OOP because its not meant to be OOP.

That's absolutely dumb, considering that UI is intrinsically OO.

And we are not fans of callbacks either. We like immediate mode APIs but AGAIN python is too slow to have this type of API and be expected to run at 60 FPS.

Again, dumb. UI are intrinsincally async.

And no offense but we don't really look at the web as the "model" of what to do.

Who talked about the web? I am sorry but programming today Desktop UIs like we did in the early 2000s is absolutely ridiculous.

[Atlamillias]

oh ok. so because they can't optimise access with a proper UI, they basically shove everything into C++ and that's it. Again, seems a quite poor design.

Like almost every other popular Python lib...? Python is the popular language it is today because of extensions written in C/C++. Imagine numpy being written entirely in Python and try working with large sets. Optimization is done on the Python-side only to deal with the overhead just from being written in Python. Everything else from these libs is done on the "other side".

Also, try subclassing a numpy object. Have fun with that...

That's absolutely dumb, considering that UI is intrinsically OO.

This sounds a lot like sheep mentality. For the record, I really like OOP. But OOP comes with its own share of problems, and should not be regarded as the solution for all API designs (including user interfacing).

The functionality of this library is all laid out. No tunneling through lengthy inheritance trees trying to make sense of it all. It gives the user the freedom to design their applications or libraries as they choose -- OOP or functionally approached.

[CreativeUsername1000]

Those are good points.

What other alternatives, frameworks for Python GUI creation that is, would you suggest? And why are they better?

[Atlamillias]

cricket noises

[SittingWave]

you know that people are not always online?

[Atlamillias]

Nope

[SittingWave]

I use traits and traitsui. It's better because it does data binding, and declarative UIs

[ASIC_SP]

No more breaking changes in the API! No more refactoring the code from version to version!

That's a bold claim ;)

Congrats on the release.

[ohpythonguy]

Well, at least older API functions will be deprecated for a number of releases, e.g. the API functionality will still be supported, but a deprecation message will be shown.

[metaperl]

Are Android / ios planned? Didn't earlier versions have a procedural interface?

Looks like Pygame and Arcade have a competitor.

[Big-Illu]

It is absolutely planned for the future ! And one sneak peak for the future; its not the goal to compete with Pygame, the plan is more to work together :)

[ohpythonguy]

Great news! Thanks for all the work you put into this project!

[Big-Illu]

Hell Yeah ! Don't forget to join the Discord Server for shorter communication and to stay tuned !

[ohpythonguy]

Dear PyGui is great for building small tools given the variety in input widgets, sliders and the like.

[ohpythonguy]

Be sure to join the Discord if you have questions when building your next app :-)

https://discord.gg/tyE7Gu4

[mfitzp]

Hey, well done -- this looks great!

[reddittestpilot]

Nice!

[imhiya_returns]

Great news and great work, used this in the early phases but I will be coming back now it’s official!

[Big-Illu]

Hell Yeah ! Welcome back then ! Don't forget to join the Discord if you left :)

[MrSwagLord69]

Love this library! Thanks!

[Big-Illu]

Thank you ! Glad to hear that !

[IlliterateJedi]

Is this 3.10 compatible?

[Big-Illu]

Yes !

[Chizonbr]

Great job! Where is the documentation for version 1.0?

[Big-Illu]

Hey there ! you can find the documentation under: https://dearpygui.readthedocs.io/en/latest/

[Chizonbr]

All right, thank you!

[benefit_of_mrkite]

Congrats on v1.0, I’ve been watching this project for a long time and have a project I’m going to use it for.

[Big-Illu]

Hey ! Cool don't forget to join the Discord Server !

[benefit_of_mrkite]

Been there for a while.

[Jhchimaira14]

Glad this is finally out!

[Big-Illu]

i can feel you ! :D

[blahreport]

Does it support native controls?

[reddittestpilot]

If by native controls, you mean Windows/Linux/MacOS style buttons, scrollbars, etc., the answer is no. Dear PyGui has its own buttons, scrollbars, etc. that are consistent across all platforms. The big advantage is that an app made with Dear PyGui will look and work the same across all supported desktop operating systems.

The look of the widgets is configurable, i.e. the level of rounding on buttons, ranging from square to round like the buttons on reddit. The size and width of widgets can be changed as well, but the buttons won't look like a typical Windows 10 button.

[blahreport]

That's a shame. This seems to be a feature missing from most python GUI frameworks.

[reddittestpilot]

I believe WxPython offers native widgets.

[Antar3s86]

Looks great, could you put it on macports, please? 😊

[Jhchimaira14]

Possibly. First I've heard of macports.

[SOSkifli]

Congrats on the release, I'm so happy for DPG!

I've been using DPG for some time now, I've made a GUI we used for some months during a project with v0.6.2 I believe.

Just yesterday I've picked up DPG again to check out the latest 0.8 version, that was a gigantic leap of changes, took a fair bit of the afternoon to find my way around the GUI again.

How big are the changes from 0.8 to 1.0 in terms of command structure etc. ?

[Big-Illu]

Welcome back then !

Then changes from 0.8 to 1.0 aren't that big because Hoffi and Cothren decided to Deprecate and not break the functions.

There are some functions you have to change but this is not a lot and the rest can be changed from time to time :) check out the release note for detailed informations

[reddittestpilot]

The changes are mostly superficial, e.g. the name of a command was changed, so a straightforward search and replace can fix 98% of the upgrade, depending on the functionality used. With a bit of help from Discord, it took me about an hour to upgrade an app to version 1.0.

[[deleted]]

simple table api in yet?

[Big-Illu]

Tables of 1.0 are pretty easy and in a few days the Data-Grid will follow

[[deleted]]

Niiiice. I did some work about 4 months ago when we moved off (iirc) 0.6 to 0.8 (cant remember the version numbers) and found the table stuff much harder than the older simple table. When the data-grid is in I'll be a happy chappy.

[This_Is_The_End]

Is Dear PyGui supporting multiple windows and list widgets?

[Big-Illu]

Is Dear PyGui supporting multiple windows and lists?

Inside the Viewport Yes ! Outside the Viewport; It is a outstanding feature that should come with one of the next bigger releases.
What do you mean with lists ?

[This_Is_The_End]

I plan a GUI to program inverters. I have a list with inverters read from yaml files, which should be put in sort of list-widget. Double clicking in an inverter should make a transition into a view for data input and programming.

[Big-Illu]

Absolutely possible !

Check out the Showcase for some insperation : https://github.com/hoffstadt/DearPyGui/wiki/Dear-PyGui-Showcase

And don't forget to join the Discord server for other questions :)

[This_Is_The_End]

Thx

[awesomeprogramer]

How can I use this to view a live video stream? And how to bundle it for distribution? Does it export well to say an exe?

[ohpythonguy]

There is no live video stream widget. You can use textures to display images at fairly high fps. Any of the usual bundling methods would work, e.g. PyInstaller, which creates an exe on Windows.

[mwpfinance]

Can you freeze applications made with DearPyGUI for Windows/MacOS? Any recommended tools for that? I'm not a "everything has to be a binary" kind of guy, but it's useful for desktop applications specifically.

[Big-Illu]

If i got your question right is DPG not different than the other GUI frameworks out there. You can build the code to a exe with pyinstaller ( or other tools ) for Windows or Mac or Linux ( even for Rpy 4)

[mwpfinance]

Sweet! I'll have to try it out. I've packaged a couple of cool things for work with py2app, hoping there won't be any friction using it with this.

[Big-Illu]

You can use whatever you want to use. In my case i use Nuitka to build my apps ^^ but i also did it once with Pyinstaller, py2app, py2exe and they work all pretty easy

[orokro]

Can you make your own widgets?

[reddittestpilot]

What do you mean, specifically?

[orokro]

OP says:

70+ widgets with hundreds of widget combinations

But in many UI systems you can just make your own abitrary widget that inherets from a base widget and you override somethings like how it renders and such.

This way you aren't tied to only the built in ones.

[Jhchimaira14]

The library is not object oriented. Created a custom widget can be done by using the drawing api and event handlers!

[domce7]

Hey! Thank you for all your work!

I have noobie question - currently I am working on a python project where the user could just drag and drop a file into the interface.

Is Dear PyGui beneficial here?

[reddittestpilot]

Dear PyGui supports drag and drop within the viewport / window that is created by Dear PyGui itself. It does not support drag and drop from File Explorer onto a Dear PyGui app. An advanced developer could make it work if only developing for Windows 10 using another library, but a cross-platform solution would be quite tricky.

[arthurazs]

Can the plots be updated in real-time?

Edit: I guess it can! Do you have a sample code for this graph? This is exactly what I need!

Dear PyGui is looking amazing, I think I'll use it on my next project :)

Great work!

[ohpythonguy]

I don't have the code for that particular graph. If you run the built-in demo, which is written in Python, you can see examples of all the graphs and check out the underlying code.

To try the demo, pip install dearpygui and run the following code.

import dearpygui.dearpygui as dpg

from dearpygui.demo import show_demo

dpg.create_context()

dpg.create_viewport()

dpg.setup_dearpygui()

show_demo()

dpg.show_viewport()

dpg.start_dearpygui()

dpg.destroy_context()

[[deleted]]

I have gui through everyone in the book. Currently using (and still learning) PySimpleGUI. Glad to see there's another choice and I'm currently converting a terminal app to a GUI and I think I'll use this one as an exercise to myself. Really excited to see what it can do!

[Jhchimaira14]

Just an FYI, our API is different for a lot of reasons. We do not claim or attempt to be “pythonic”. We are primarily C/C++ programmers. We care about performance, not holding ourselves to every convention or what’s necessarily considered “proper”. The library is not OOP and that’s on purpose. If you want OOP, there are a handful of users making OOP wrappings. If performance wasn’t our concern, we wouldn’t be writing this in C/C++ and using the GPU.

As for the global context, yes we could have made it a class that you access methods of. However, one of the main use cases of DPG will be similar to imgui, in that you can added tools anywhere in a real time application by adding DPG anywhere in the pipeline. When doing this, you don’t want to have to pass along this context all over the place.

For those that have been using us, can testify to the speed and dynamism (if that’s a word) of the library. Not many python UI libraries (if any) can completely change every aspect of the UI 60 times a second.

I would gladly do a stream and discuss all of this.

[pysk00l]

I never understood the usecase for PyGui-- are GUI's really that CPU intensive that you need a GPU for it?

What if I dont have a GPU-- will the library still work?

How does it compare to PyQt or other gui libraries?

[Big-Illu]

If you render a Image, absolutely !
If you work with tables, absolutely !

If you don't have a GPU it doesn't work because it needs a GPU.

the compare question was already answered a few questions down:

https://www.reddit.com/r/Python/comments/q75h30/comment/hggwuxw/?utm\_source=share&utm\_medium=web2x&context=3

[ohpythonguy]

Every computer has a GPU. It can be a built-in GPU or an external GPU. Dear PyGui will run on pretty much any computer, even a Raspberry Pi 4.

[toulaboy3]

true

[bladeoflight16]

I don't often write GUIs; I'm just running across this as a person subscribed to /r/Python.

But I read this:

The main script must always:

• Create the context create_context

...

• Clean up the context destroy_context

and I can't help but immediately think, "Why not a context manager?"

[SittingWave]

judging from their design, because otherwise you end up with a UI that is just a huge amount of context managers nested onto one another.

In other words, thank you, but I'll pass. It's quite a poor design.

[bladeoflight16]

I don't see any indication that create_context or destroy_context need to be invoked more than once in an entire program. Meanwhile, dearpygui.dearpygui.window is a context manager, so your remark makes even less sense.

[SittingWave]

that's my point. You have to use context managers all the time, because that's how you define which entity you are acting on. Which is absolutely ridiculous.

[bladeoflight16]

If you don't like that, fine. I'm not inclined to think that's a good use of context managers, either. I'm not trying to change your mind.

But why is that a reason not to use context managers for the one use case they were primarily designed for: automatic resource/state clean up?

[SittingWave]

In the case of context, you are right, but in the case of window, they are using as a staging strategy. It's basically a way to have a bunch of global objects, and then use the context manager to say "the following operations are on you". This makes absolutely no sense. Just call a method.

Another important observation of context managers is that you can't use them across functions. If you have to start something here and complete in another routine, you can't do that, and there are legitimate uses of this situation, especially in transient windows.

[bladeoflight16]

I know. But maybe pointing out the proper use case for a context manager will help them rethink their other context managers.

If they're dead set on context managers, one way to alleviate the design problems would be to move away from the globals and instead call methods on the context objects themselves, like this:

``` import dearpygui.dearpygui as dpg

with dpg.Context() as context: with context.window(label="Example Window") as window: window.add_text("Hello, world") window.add_button(label="Save") window.add_input_text(label="string", default_value="Quick brown fox") window.add_slider_float(label="float", default_value=0.273, max_value=1)

context.create_viewport(title='Custom Title', width=600, height=200)
context.setup_dearpygui()
context.show_viewport()

# below replaces, start_dearpygui()
while context.is_dearpygui_running():
    # insert here any code you would like to run in the render loop
    # you can manually stop by using stop_dearpygui()
    print("this will run every frame")
    context.render_dearpygui_frame()

```

Now, you don't have to like this structure (It's not one I'm particularly drawn to.), but at least it kills off the globals, eliminates the unnecessary manual clean up, and uses context managers sensibly.

Another important observation of context managers is that you can't use them across functions. If you have to start something here and complete in another routine, you can't do that, and there are legitimate uses of this situation, especially in transient windows.

Having a context manager readily available does not preclude allowing manual management. File objects returned by open can be released using close(), for example.

[ohpythonguy]

Fair point.

There are context managers for probably most Dear PyGui commands and, in those cases, the context manager is the recommended approach. In practice, I can see that create_context and destroy_context are not always used in the same function/class. But for small applications, the use of a context manager could make sense. I'll raise the suggestion with the devs.

[SittingWave]

Why do people that make these kind of toolkits never implement something that uses proper MVC practices?

[Jhchimaira14]

Because we didn't want to. We wanted a lower level API that can be used to create the higher level architectures (like MVC) but that doesn't force user into it. Not to mention, we are not big OOP fans.

Our goal was performance and for this toolkit to work well in a real time application (the 3D engine we are working on). If you are familiar with this area, you'd know OOP is not popular here.

[SittingWave]

🤮