#348: Dear PyGui: Simple yet Fast Python GUI Apps Transcript

00:00 I'm always on the lookout for a good Python UI framework.

00:03 In this episode, we're going to focus on one called DeerPyGUI.

00:07 DeerPyGUI is a fast and powerful graphical user interface toolkit for Python with minimal

00:12 dependencies. It's created by Jonathan Hofstad and Preston Cothran, and they're here to tell

00:18 us all about it. This is Talk Python to Me, episode 348, recorded November 18th, 2021.

00:24 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.

00:42 Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes

00:47 at talkpython.fm and follow the show on Twitter via at talkpython. We've started streaming most

00:53 of our episodes live on YouTube. Subscribe to our YouTube channel over at talkpython.fm

00:58 slash YouTube to get notified about upcoming shows and be part of that episode.

01:03 This episode is brought to you by Sentry and TopTal. Please check out what they're offering

01:08 during their segments. It really helps support the show.

01:11 Let me tell you about a new project I'm working on. It's a YouTube series called Python Shorts.

01:17 This series will consist of fun and quick videos teaching you one amazing thing about Python.

01:22 They're usually less than five minutes long and put a practical spin on topics you might have been

01:27 and counting the number of times an item appears with collections.counter. I already have a list of

01:39 about 100 videos to create over the next year in this series, so there will be many more to come.

01:44 And if you have an idea for one, please shoot me an email or tweet and I'll add it to my list.

01:48 If these sound fun, please subscribe to my personal YouTube channel. Just visit talkpython.fm

01:53 slash python dash shorts to see the playlist and there you can click on my face and subscribe.

01:58 You may already be subscribed to Talk Python's YouTube channel. That's where we do the live

02:03 streaming of the recordings, but I decided on my personal one. So be sure to subscribe there too

02:07 if you want to get these videos. Thanks for listening and thank you for supporting all of my work.

02:12 Let's get to that interview. Jonathan Preston, welcome to Talk Python to me.

02:17 Hi, glad to be here.

02:18 Hey, it's great to have you guys here. I'm very excited to talk about GUIs and UI frameworks and

02:24 stuff like that. I think Python needs more of it and we're building some cool projects,

02:30 frameworks there. It'll be fun to talk about it. We're going to talk about DeerPyGUI,

02:35 which is one of these frameworks tries to have a quick getting started story.

02:39 That is correct.

02:40 Let's just get into your stories and hear a little bit about you since there's both of you,

02:45 maybe not too extended, but Jonathan, how do you get into programming in Python?

02:48 I got into programming when I was around 13 years old. My stepdad and mom got me a C++ for dummies book.

02:57 And worked with that for a while until just as a hobby project or as a hobby thing. And once I got to

03:05 college, I went to mechanical engineering, which is also where I met Preston. They typically like to

03:10 use MATLAB, which everybody knows isn't a real programming language. The indices start at one.

03:15 Of course.

03:16 As an alternative to that, ChemCurls Python. It had a lot of the same features, actually a lot

03:21 more features than MATLAB and it was free. So didn't have to pay for the MATLAB license.

03:28 Yeah. MATLAB is expensive for people who haven't messed with it. It's like really expensive outside

03:33 the student story.

03:34 It is. And you have to use their entire environment and everything just to, just to use it. So aside

03:41 from that, on top of that, with the Raspberry Pi, it was into electronics and things like that. And

03:46 the Raspberry Pi are able to control the GPIO pins using Python. Naturally, I just started playing

03:52 with Python from there. And yeah, that's pretty much where Python came into my picture.

03:57 So you said you were in chemical engineering? Is that what it was?

04:00 Mechanical.

04:00 Mechanical. Okay. I was in chemical for a little while and they said that, I asked if I could take

04:06 a C++ class. They said, you can as an elective, but you have to take Fortran because that's going

04:09 to be the most important language you ever learned. I thought, I'm just jealous. MATLAB is not that

04:13 amazing, but I'll tell you what, it's better than Fortran.

04:15 That is very true. We occasionally have to use Fortran at work with our FEA programs,

04:22 finite element analysis programs with Abacus. You're able to extend it with Fortran. So

04:26 occasionally we have to look at a little bit of Fortran to do that. And it's, yeah, it's ugly.

04:30 Yeah, for sure. Preston, how about you?

04:32 Mine was mostly junior year in college, MATLAB course. Incidentally enough, that's why it's not

04:38 a real programming language. I moved from that directly into Python. I thought when I started

04:43 my first job and I just started working with C++ after that and then tailed into a little bit of C,

04:49 not much. Right on. And what are you all doing now? Sounds like still engineering work?

04:54 Yeah. So I'm doing engineering. So I'm doing mechanical engineering. I'm doing design on

04:58 threaded connectors for oil and gas industry, mainly designing the seals and threads that hold

05:04 production tubing together down hole that actually sends the oil up through the well.

05:08 Wow. So you must be talking about a lot of pressure, talking about materials that would

05:14 like to destroy rubber and other things as well, possibly.

05:16 Yeah. So I guess that, that tails into coding. Mainly we, or I use most of Python to just extend

05:24 that because like we were talking about for scripting and stuff like that.

05:27 Yeah. Jonathan?

05:28 I started out in the same position and slowly moved into the software side of things. A lot of that's

05:35 working with Preston, some of the other mechanical engineers on extending some of those applications

05:40 like Abacus and that choosing Python or extending AutoCAD and that's C++. So there's that side of

05:47 the day-to-day work. And then the other side is we actually have some internal software that

05:51 we work on one for inspecting connections without contact. So using lasers and robot arms and all

05:59 that stuff to basically just take measurements instead of having to go out and manually doing

06:04 it. This, this can be on an assembly line and most of that's in C++ and C. We do use our library,

06:12 DeerPock GUI for a lot of the prototyping and some of the tooling for the project, but for projects in C and C++.

06:20 Sure. I don't think I've really covered mechanical engineering on Talk Python properly. What's the

06:25 story with software automation and that kind of stuff? Is it mostly using programs like sounds

06:31 like this Abacus one versus writing your own software, doing your own automation?

06:36 A large part of mechanical engineering is, at least in our field, is stress analysis and computational

06:45 fluid dynamics, fluid flow type problems. And as far as software goes, it's usually in relation to that.

06:51 Like Abacus is, as an example, a software package for stress analysis. And then there's other ones,

06:57 OpenFoam.

06:58 Yeah, OpenFoam. You, you wrote some solvers at your first job for that?

07:02 Yeah, that, that's correct. We took some electives while we were in college and some of those were for

07:09 writing these solvers. And most of those you could write in whatever you want. Those professors didn't

07:13 actually care. And a lot of times I wrote in Python on there. Most of the time it was Python, I would say.

07:16 Yeah. What's the story for packages, PyPI type of things in your space?

07:22 As far as what we used or what we used?

07:25 Yeah. Is there a lot of stuff out there? I know, for example, astronomy is filled with libraries,

07:30 like AstroPy and whatnot that people could just grab and use.

07:34 For mechanical engineering, I don't know if there's NumPy or NumPy.

07:38 Yeah.

07:38 Yeah.

07:38 But as far as specific to mechanical engineering, I really don't think there's any. There may be a few

07:43 FEA solvers, but I don't think they're maintained or well documented for sure.

07:47 We typically found that a lot of engineers end up staying in the MATLAB realm and not really venturing

07:52 into any more hardcore languages. So they end up using all, because a lot of them want symbolic math,

07:59 integration and ODE solvers and all of that. It's all right there in MATLAB. And then the companies

08:05 typically pay for it. So you're in that realm.

08:07 And once some group gets embedded in there, it's just going to stay in that space unless somebody

08:12 takes some effort. Yeah. All right. Awesome. Thanks for that background. Although we're not here

08:16 exactly to talk about deep dive in mechanical engineering, it is cool to get a look. Let's talk

08:21 about your project, your PyGUI. So when I think of the GUI graphical user interface space

08:29 in Python, there's TK-Enter, there's PyQt, there's a few other things, but they all have some kind of

08:37 oddity about them. There's not like one framework that people just like, yeah, we're just going to

08:41 use that thing. It's not like a Swift and Objective-C Coco controls would be in say,

08:47 an iOS app or something, where it's really clear. Just generally use that one. Where did you guys get

08:51 started working on GUIs and Python? What was the goal with the Geopy GUI? Like where does it stand

08:55 out? Where does it fit in this space? I got started in UIs working at one of my internships while I was in

09:02 school. And we were using this package, which I think I already mentioned once, open foam for CFD.

09:09 And it didn't have a front end interface at all. It was a C++ solver that just pretty sure just output

09:16 text files in the end. I don't remember. It's been about six, seven years. So I wanted to build a UI so

09:21 that the other engineers could use it. And at that time, I was just getting into it. So I used to Kentr

09:27 because, you know, it's a Python. And then also used VTK, if I remember correctly. That would,

09:32 I would say that's the first experience I had with it. And then our senior design project,

09:37 being pressed were also on the same team for that, was to build an arc welding 3D printer.

09:42 It actually created things by doing arc welding. Right.

09:46 Rather than printing some other sort of material out of it.

09:49 Right. Yeah. It was a MIG welder. I was on the software side of that. Preston was on a lot more

09:55 of the physical side. We should put them in the software for now.

09:58 Yeah. Anyway, built, that was the goal of the project. And we used some open source

10:04 slicing software. I don't remember. It's like Slicer 3D or...

10:07 It had a three for the E. Yeah. Slicer and it had three for the E. And we basically modified that

10:13 and ran it in a headless mode and built a UI on top of it using Tkenter. And I want to say we used

10:19 Pygame to be able to access OpenGL. And at the time we were using legacy OpenGL. Those are first

10:25 experience with graphics APIs. Yeah. Which, you know, OpenGL is pretty neat. It was certainly

10:31 good when it first came out. It was as good as anything else. But I feel like it hasn't been

10:36 getting the same amount of growth and adoption, maybe as some of the other frameworks, DirectX and Metal and

10:42 so on.

10:43 DeerPyGUI uses DirectX, Metal and OpenGL at the moment. So we've been using a lot of them over the last few

10:50 years. And the biggest reason for that is just that the hardware's changed since those APIs were

10:58 created. And they no longer directly match the hardware.

11:01 DeerPyGUI came out of trying to basically build something better than direct OpenGL access. What'd

11:08 you say? Or direct framework access?

11:11 DeerPyGUI not quite. It came more out of a, I guess, going back to answering where

11:15 where DBG itself came from. We had a previous project that we worked on, a commercial project

11:20 on engineer sandbox. The program had an embedded Python interpreter in it. And you basically created little

11:28 mechanical engineering apps. And we could create one in, I don't know, an hour or two. And it was just

11:35 this collection of apps. And over time, it started to get a little annoying to have to recompile it,

11:41 especially before we added Python. We added Python because we were getting tired of

11:45 recompiling it every time we want to add an app or modify something and have to redeploy.

11:49 From there, we embedded Python. And it was very limited. You were able to create a few

11:55 small apps. You couldn't, it really wasn't a full GUI library. What happened is we were trying to sell it.

12:01 Didn't really work out. We can never really catch traction. And we had some users and customers,

12:06 but most people weren't really interested in it. And developers aren't really interested in paying for

12:11 libraries or any SDK. Most of them just wanted to be free. So that just kind of fell out. And we gave

12:19 up on that after that. That's a tough place to be, right? You want to put a lot of energy into building

12:23 tools and making stuff for people. How do you put enough time into it if people just want it to be free?

12:29 Maybe what we got to do is maybe the world is the VS Code model where there's large companies that have

12:36 other motivations for creating it rather than directly funding through that. But that's a deeper

12:42 conversation that we have to solve.

12:44 Selling to developers in easy is the key point there.

12:47 Yeah, sure.

12:48 So we did keep it in house and we continued. We still have apps written in it at our day job.

12:53 We ended up revisiting it because it didn't do everything we wanted to do. And we said,

12:56 this time let's target developers from the beginning. So it's not going to be very limited. It's going to be,

13:01 should be able to do most things you can do in any other UI library. And on top of that, make it free.

13:06 And that's where your PI GUI came from. And between those stages, we came across the library

13:14 or in GUI, which I'm not sure if you're familiar with, but...

13:17 Yeah, I'm not familiar with it. What is this?

13:19 It is a...

13:20 It is an extremely popular immediate mode graphical user interface for real-time applications.

13:28 It's usually used.

13:30 C++.

13:31 Yeah, it's C++.

13:32 Yeah, yeah, yeah.

13:33 But it's kind of a weird, I mean, it's an immediate mode interface and there's not many,

13:38 I would say there is no Python user interface that's like that. And if you look at it...

13:43 Maybe we should talk about the different modes real quick, since you bring it up.

13:47 This immediate mode versus retained mode. What are those two worlds? What does that mean?

13:53 I take this one.

13:53 So I don't want the internet to jump on me here because there's a lot of...

13:57 A little bit of argument there, but there's a few key points, I think, that really make it stand out.

14:04 One of those is that the stage is not retained. If you have a slider that controls a float,

14:11 it doesn't... You don't have to basically have a float stored on your side and a float stored in the UI,

14:17 and you're constantly having to deal with keeping them up to date and things like that. Instead,

14:22 the library itself doesn't store that at all. Now, the way it's implemented is a little different,

14:27 but I'm talking about from the user side of using an immediate mode library.

14:30 It doesn't retain any state. The other big thing is that, at least with, especially when it's on GUI,

14:36 is the UI items and widgets are submitted every frame. So 60 times a second. And that gives you a

14:44 credible amount of dynamicism, I guess you'd call that. To be able to do a lot of things,

14:48 and completely redo the UI on a per-frame basis, you can...

14:52 Yeah, as opposed to something where maybe you say a text box goes here and a button goes there,

14:58 and then you set the text to the button, and then the button knows what its text is.

15:01 This is almost like a game loop type thing where it...

15:05 Right.

15:05 Each time, like however, whatever the frame rate is, 50, 60, 200 frames a second, it's like,

15:11 draw the UI, draw the UI, draw the UI, right?

15:13 Yep. And the interesting that that kind of 60 frames a second can lead into what we just put in a few

15:19 weeks ago talking about not redrawing the GUI every 60, every frame.

15:24 Right. That's a good point. One of the issues we had, especially early on with some users complaining

15:30 as well, do you need to update everything every frame 60, 60 times a second?

15:35 So we did recently add in 1.1, the ability to basically stop, only update if there is some

15:41 user input, whether that's moving the mouse or resizing the window, things like that, because

15:46 a lot of people, they'd complain to be more energy conscious with having your GUI run all the time.

15:51 Which you might care about, say, on a laptop or a tablet, but less so if you're plugged into the wall.

15:56 Right. Yeah.

15:57 Yeah. Interesting. Yeah. And even some of the new, what are they, ProRes displays,

16:03 like the new MacBooks and stuff? Like the entire display will slow down if stuff is not happening.

16:09 And I wonder if maybe if you had a GUI app that was refreshing the screen a lot, maybe it would

16:15 prevent it from actually going into a slower mode.

16:17 Look and do that. Variable refresh rate plays into the software actually rendering.

16:21 Yeah. Yeah. Yeah. I don't really work at that level, so I don't really know for sure, but all in the same

16:27 space, I'm going to go back to the app. This portion of Talk Python To Me is brought to you by Sentry.

16:32 How would you like to remove a little stress from your life? Do you worry that users may be

16:37 encountering errors, slowdowns, or crashes with your app right now? Would you even know it until they

16:43 sent you that support email? How much better would it be to have the error or performance details

16:48 immediately sent to you, including the call stack and values of local variables and the active user

16:53 recorded in the report? With Sentry, this is not only possible, it's simple. In fact, we use Sentry on

17:00 all the Talk Python web properties. We've actually fixed a bug triggered by a user and had the upgrade

17:06 ready to roll out as we got the support email. That was a great email to write back. Hey, we already saw

17:12 your error and have already rolled out the fix. Imagine their surprise. Surprise and delight your users.

17:18 Create your Sentry account at talkpython.fm/sentry. And if you sign up with the code talkpython, all one

17:25 word, it's good for two free months of Sentry's business plan, which will give you up to

17:30 20 times as many monthly events as well as other features. Create better software, delight your

17:36 users and support the podcast. Visit talkpython.fm/sentry and use the coupon code talkpython.

17:42 It looks to me like that some of the, there's some similarities from the I am GUI in terms of the

17:50 UI look and feel, but then you've got the retained mode versus immediate mode and things like that.

17:56 What's the relationship between these? I'm GUI itself.

17:59 I'm GUI itself just outputs. You can read as read me, but outputs and optimize vertex buffer.

18:04 It sends basically the coordinates and everything needed to draw the UI, but it is up to you to take

18:10 that and actually do something with it and render it. We use that. We use I'm GUI to basically create

18:16 those vertex buffers. As far as the retain mode stuff, originally we were doing more of a one-to-one

18:21 wrapping with that library. And we started to hit some performance issues with Python itself, just because

18:29 the second, if you're having to do a lot of conversions between maybe the Python types and

18:34 the C and underlying C types that can slow things down. Also just the GIL gets in the way with a lot

18:40 of different. So what we did with the retain mode is we basically just created a barrier between that,

18:46 where we do go against the immediate mode style thing. And we have, we do keep up with things like the

18:52 the underlying value is just the floats, the, the ends, the strings, whatever it is.

18:56 So it goes back to a more retain mode, which is what every other library is that most Python users would

19:01 be used to. The float actually stores a, sorry, an input text has its underlying string and you can

19:07 get that value, set that value.

19:09 So a lot of UI code, you don't even need to have some variable that holds the thing. You might just

19:15 put it in the button and if you need it back, you could get it from the button potentially. Right.

19:19 Right. Yep. And that's how it works. So I guess one of the only other things that's neat is underneath it,

19:25 it is just a raw, I'm pretty sure probably using smart pointer and you can actually link a lot of these

19:30 widgets together to when they're truly controlling the same value. And you can get some pretty cool effects

19:36 with that to where directly moving this slider is updating the plot and there's not some update

19:42 code that's having to happen or any callbacks. It's just that they're truly the same value.

19:47 And because we're updating 60 times a second, you're able to see those changes live, which is pretty

19:53 neat. And you can create some pretty cool stuff with that. Yeah, that's fantastic. Before we jump into some

19:58 of the details, if you visit the GitHub page, which of course I'll link to, let's maybe just talk through

20:03 some of the features. I was going to go to the gallery, but maybe the features is a better place

20:07 to start. And you guys have this engineering background. It feels like a lot of what this

20:12 creates and allows us to build real easily has this engineering visualizing aspect to it. Right.

20:19 Yeah. Yeah. So maybe talk us through some of the features and things you can do. So for example,

20:23 one of the things you have, you can see right at the top of the feature section is the I am plot stuff,

20:30 which looks like really interactive and dynamic plots and graphs and pie charts and so on.

20:35 Yeah. It's another immediate mode interface that the guy that wrote it, Evan Peasant, I'm not sure

20:43 how to pronounce his last name, who also happens to be located here in Houston, wrote it on top of

20:46 on GUI and tried to model that immediate mode interface. So again, you get all the same dynamic

20:51 features that you get with GUI itself. And that's why you can see on here a lot of the, just how crazy

20:57 dynamic it looks, right? With the live QCAP clearing and everything you see there. And obviously we,

21:03 again, built on top of it because we have to go from that immediate mode to retain mode style. And

21:08 it, you have multiple axes, you have drag and drop support, custom drag and drop support. There's a lot

21:15 of series you don't see there, candlesticks, shaded series, stem plots.

21:20 Yeah. One that looks really good is this one down here that has full zoomed out graph and then a graph

21:27 below it that as you pan around and zoom in, you can actually, it's like a high level and then a low

21:34 level or zoomed in detail view of what you're exploring there. Yep. And that's pretty obituary

21:39 than the demo. Well, it's actually not technically built in. That's a query region. So you have to

21:44 set up another plot with the same. Also, it looks like they have animations and stuff. The one below

21:50 it sort of just cruising by without any interaction. So are you able to just feed it live data and it just

21:56 keeps refreshing 60 frames a second or something? Yeah, that's exactly how it's working because it's,

22:02 again, already updating 60 times a second. All you're doing is changing the data and it just by

22:07 default, you basically get an animation. If the data changes, it's going to re-render it no matter

22:12 what. And so then it gets a different picture, right? Yep. It's worth noting that it's only 60 frames a

22:18 second. If you, if you use VSync with your, with your screen, it actually runs as fast as your screen

22:22 can run. So 144 to whatever hertz your monitor is on. Oh, interesting.

22:27 It depends on your GPU and everything else. Yeah. We'll control the render loop so you can actually

22:33 slow it to whatever exact frame resolution you want. You could 30, whatever you want. Right. You

22:37 probably can't exceed your monitor, but you could slow it down or do something if you need to chill it out.

22:43 You can, it just won't.

22:45 The effect of, the effect of people seeing it, they won't see it. Right. Yeah. And that, yeah,

22:50 that's really cool. Cross platform. Yeah, it is cross platform, but I was going back there. There are

22:55 some cases where we will turn VSync off to just test how fast certain things are happening. Right.

23:00 Because you want to know what's the performance upper limit of this, regardless of the screen.

23:05 the screen. And a lot of people love to send us messages with that while we're trying to do

23:08 something like update a texture or something as fast as they can and trying to get 300 or 400 frames a

23:14 second. But it was pretty neat to see that. What else should I highlight in here? These are all,

23:19 there's a bunch of graphs. I think people really just need to go see them, but there's,

23:22 there's nice heat map looking things. There's some statistical stuff. Anything else you want to shout out on the.

23:29 Yeah, there's some candlesticks. We've seen some great interaction with some APIs through some actual

23:33 cryptocurrency interfaces people have done. They made crypto wallets, which is pretty cool. We've seen some of that.

23:38 Right. Yeah. So we've seen probably maybe 10 of those. So it is a lot of people seem interested in that.

23:42 Interesting. Yeah. So people are using DearPyGUI to build something like a dashboard trader application.

23:51 A lot of dashboards. Yeah.

23:52 We can pull in a comment from the audience, Mr. Hypermagnetic. Hey, good to see you again.

23:58 I've always been curious why not use HTML for desktop GUIs. And then also adds that these are

24:03 definitely nice looking graphs and user interface, which is cool. Maybe I'll let you all take a shot

24:07 at answering that question for you. If you got that, if not, I could throw something out there as well.

24:12 Because we got a ton of Electron apps that fit that realm.

24:16 That's what I was going to bring up with Electron.

24:17 And VS Code and other things, Slack and whatnot. I think there's a couple areas that you would care

24:24 about. One is you probably are not going to be getting 300 frames a second refresh rate with HTML.

24:31 There's a lot of layers in there. If you want to take advantage of the GPUs in like deep ways,

24:37 if you want to push a mesh of objects in there and then have them re-rendered, that's not really what

24:42 HTML is for. The native integration also gets tricky. I don't know about Geopie GUI,

24:48 but you want to integrate with the menu bar and other stuff, right?

24:51 Yeah, we need the hardware access. Now you can use WebGL, but basically you'd be using HTML just to

24:59 create that GL canvas. And then after that, it's the same thing as what we're doing now. So you could

25:05 do that. I think we have some sample projects where we use that. You can get 60 frames a second higher,

25:10 but again, you're just using HTML just to get to the canvas. And then after that, the HTML is gone.

25:15 Yeah, you'd use it for anything.

25:16 Let me see here if I can get a quick read on say like VS Code here. Hold on. A little activity monitor

25:24 doesn't.

25:25 If I happen to run through the browser, there's your text stat becomes considerably deeper when we're

25:32 trying to be as light as possible.

25:33 Yeah. Yeah. If you want to do a lot of the stuff that we're seeing on the screen here,

25:37 you're almost down to rendering directly on canvas. And then at that point, there's not a huge value

25:42 for the HTML side of thing because you're just drawing pixels anyway. So to wrap that up,

25:48 I'm a trap hypermagnetic says I've seen performance issues with electron versus more native apps.

25:54 Antonio out there. Hey, Antonio. Good to see you. Loves these plotting features. He's also in the oil

25:59 and gas industry. So very, very cool. Great. And following up on that, John says there's also a

26:06 limitation to threading and concurrency, which you definitely have more control, right? Very quickly.

26:11 So for example, like I just launched VS Code and it's doing nothing. And there's one,

26:16 two, three, four, five, six, seven, eight, nine, 10 processes running VS Code, which quick math

26:22 across those looks like something like 350 megs of RAM. I don't know what your pipe would take,

26:28 but I suspect it would be far lower than that.

26:30 It should be much lower.

26:31 So you're multi-processing and so on. It's pretty neat. Although Python itself is not known for its

26:37 massive, taking advantage of multi-core stuff because of the deal. Still, you got a little

26:42 more flexibility. Cool. It's always interesting to think about. Now, let's see, let's scroll down and

26:47 look through a few more of these pictures here. So you've got this node editor and this node sounds like

26:53 a core thing in this UI framework.

26:56 Yeah. That's another one of those libraries that somebody had built on top of GUI. It's usually

27:03 just a single file and a pretty light. A lot of people made some really cool stuff with that

27:07 because you could put any widget that's in the UI library in these nodes.

27:12 So let me take a shot at trying to describe what this looks like for people listening.

27:16 You can check out under node editor on the GitHub page. It almost looks like a database diagram

27:20 where you've got relationships between these nodes. But instead of just having table info,

27:25 you've got graphs, you've got XY values, you've got other little bits of computation and stuff that are

27:31 visually in the nodes that are also connected together. That looks pretty cool.

27:35 Kind of like a data flow thing, which is an actual picture you're looking at. It is a tool we built here

27:40 at work to prototype some of the systems that we're working on here. We took a little piece of that as

27:46 a snapshot. But yeah, it's a pretty cool feature. A lot of people do a lot of cool things with it.

27:51 So it was the idea I could build a little section that will take in some, let's say, fluid flow rate and then

27:58 apply some algorithm and visualize that. But then it also is an output value that can be flow

28:03 passed on to some other simulate part of a simulation that's also showing up there and stuff. Is that my understanding?

28:09 Yeah, that's it. And you can redirect the inputs from one to the output of the other

28:14 or whatever widget that are being connected, whether it be a slider and input or radio box, any of those.

28:24 And it's a pretty low level. Some of this stuff can be a little bit misleading when you look at it and

28:29 it looks like it should just come around out of the box. And most of these are not. For instance, the this node editor that you're looking at

28:35 in general, you create these nodes. And when a user tries to grab one of the pins and link it to another one,

28:40 another one, the callback is ran and it's up to the actual user to decide whether to make that link

28:46 where it's given information about where it came from, where it's trying to connect. So it's really up to the user to make something with it. It's pretty low level. And you'll notice that with a lot of these, even in the plots, they're low level. And it's meant for the user to wrap on top of and build more complex.

29:01 I don't know. Because we want it to be as generic as possible.

29:04 There's an example of Tetris, like who doesn't love Tetris, of course. What is this last one here? Several tools to help developers.

29:11 There's a lot of built in tools.

29:15 As far as it's like tab, tab views and list views and stuff like that. Or what are we talking about?

29:20 As an example, like you create whenever you go to create the UI, you may create a window and then add a group and then a collapsing header and then a button. And you have this parent relationship. One of the tools is the item registry. And when if you just type in the command show item registry,

29:35 you get this basically tree view where you can look through all the items in your UI, click on it, see information about the state of it. Is it visible? Is it clicked on? Is it hovered? That's one of them.

29:46 Most of these use for debugging.

29:48 Yeah, it's mostly.

29:49 Yeah, it's tricky to get a view into that kind of stuff in the UI, right?

29:53 Right.

29:53 Obviously, you can print out something or set a breakpoint and see it. But a lot of times they're hierarchical and whatnot. And the right visualization of that makes a big difference.

30:01 Another great one is to say, if you're loading a texture or a couple of textures into the texture registry, preparing them to be added to a widget, you can use the texture registry viewer to actually go in and inspect your different resources. Like you can preview it before you actually use it.

30:18 Oh, that's really cool. Yeah.

30:20 And with fonts, you can inspect fonts and other things like that.

30:23 Is DeerPy GUI primarily focused on 2D UIs? Or does it have a 3D component?

30:29 Right. So we are currently it's 2D, but we are working on a 3D engine to go with it.

30:35 But the UI won't be 3D, but there will be 3D widgets and we can have support for that now, but it's not hardware accelerated. The actual 3D engine we're working on will be.

30:43 Yeah, cool. So for example, like all these charts that are on the GitHub page that are active and moving, like I can totally imagine that one of it is spherical or it's, it's modeling.

30:54 You know, it's spikes that represent peaks of some kind of measurement all over the place and you want to look at it from different directions and whatnot.

31:00 Yeah. And I think at the bottom of the readme you can see some examples of users that have already skipped ahead and hacked into some 3D work.

31:09 Yeah. Like there's a gallery section that people should check out. One of the things I really like to do when I hear about a new UI framework or some tool that does UI graphical stuff is to just go look at the screenshots and go, what I want my app to look like this.

31:24 Maybe that looks pretty cool. Let me take the time to learn it. Honestly, it blows my mind. There's a lot of UI frameworks out there that don't have a single screenshot of what your whole job is to build pictures. Show us some pictures.

31:37 Yeah, really important gallery part of it.

31:40 Yeah, the gallery is looking really good. So one, it looks like almost the first one is almost like an AutoCAD thing. It looks like some kind of turbine or something is there. Maybe you know more about it. You guys can see them.

31:51 One of the users made it wasn't sure what they were working on. We helped them a little bit with getting access to the underlying OpenGL context because that was on Linux, but not sure what they were working on past that.

32:02 This next one looks like some kind of modeling system. Another one of those user saw a user with it. We snapped the photo and again, no idea what they were doing with it. Just looked cool.

32:12 Definitely looks cool. Bunch of left-hand side, right-hand side elements here. Almost looks like it could be modeling some sort of machine learning thing, but I don't think so.

32:21 Yeah, definitely some kind of interesting model here.

32:24 It might have been.

32:25 Some really nice visualizers here for, it looks like maybe looking at some astronomy stuff, which is great. And then a game and some more drawing tools. Yeah, here is this maybe a ray tracing?

32:38 No, that was just a Phong, just a Phong render that we're working on when testing some of the earlier versions of the 3D engine we're working on.

32:47 Mm-hmm. Okay.

32:48 So that's just some of the early prototypes. And we thought it was a pretty neat picture to do. And you can do that now if you just kind of, like that other user did, just hack in and get access to the OpenGL context or GrimDirect tags.

33:00 Okay, so one of the things it sounds like you can do is work with your PyGUI, but when maybe there's some low-level thing you need to do, like a shader context or some weird graphical thing, if it's not directly supported, you can just go, all right, let me just get straight to the OpenGL context object.

33:18 All right.

33:20 That's correct. And for now, that's the way it's done. But one of the things that we've been working on, and a lot of the users have been around a while and know this is, like I said, right now, the backends are Windows, we're using DirectX 11.

33:38 We're Linux, we're using OpenGL, and for Mac, we're using Metal. That was early on, that was probably a bad decision. So now we've been working on replacing the backend with Vulkan across the board.

33:49 And part of that would be that we'd be able to directly support giving users access to the GPU there. Because one of the things with the library is we do want it to be cross-platform and not have to change the code, pretty much not have to change the code at all across the platform.

34:02 Right.

34:02 Right now, with us using different backends, we wanted to expose access to compute shaders. But when you're on Windows, you'd have to write in HLSL. When you're in Mac, you'd have to write it in whatever the language is, Metal.

34:14 And then in OpenGLSL. So by switching to the Vulkan backend, we're going to be able to expose that and use the same thing across the board. And that's part of one of the big things that we've been working on. And it's taking a lot of time, but in the 3D engine itself is also going to be written in Vulkan.

34:31 I see pictures of that too, by the way, on the...

34:34 Okay, where do I find those?

34:35 Go to the very top. You might have to actually click on my name, but it's dp3d.

34:40 Oh, got it, got it. Okay, so it's a separate repo up there.

34:43 It will be combined. It's just while we're prototyping.

34:46 Sure, sure. Right here.

34:47 And by the way, nice GitHub profile. Your nice readme looks good.

34:52 Yeah, here you go. So the DeerPy GUI 3D engine. Pretty neat.

34:57 Oh, look at that. Yeah, you do have some cool pictures in here.

34:59 That will be...

35:01 And that's the stuff you need, true 3D stuff.

35:02 Yeah, that's true 3D, real time.

35:05 Let's go back just for a minute on this cross-platform business, because I think this is worth thinking about.

35:11 First of all, I was really impressed that you had support for DirectX and Metal and OpenGL,

35:17 because that means on Windows, you get the best option there, which is DirectX.

35:23 On macOS, especially in the new Apple Silicon ones, if you want to take advantage of the GPUs that are built in there,

35:30 the best way to do that is Metal and so on.

35:32 But yeah, those APIs are super different.

35:35 So if you're going to expose them, say, here, let me just hand you the low-level context and talk straight to it.

35:42 Well, setting them up for getting locked into one or the other, plus also having to learn Metal and or learn DirectX and all that, right?

35:50 And again, that's part of the reason we are switching to Vulkan.

35:53 We will leave those backends as legacy.

35:55 Legacy is a bad word, but you'll be able to switch to those backends.

35:58 But if you're really wanting to do the low-level stuff and wanting to access the 3D engine, you will have to use Vulkan.

36:04 Yeah, so tell people about what this Vulkan thing is.

36:06 I've heard of it as a way to have one API that talks both DirectX and Metal and OpenGL or something like that.

36:13 Is that sort of the deal?

36:14 OpenGL, DirectX 11, and I guess that's the two main ones.

36:20 The older, I guess the previous generation graphics APIs, and those are used to, they go through the driver and they talk to your GPU directly.

36:27 Like I said earlier on in this, that basically the hardware has changed considerably since those APIs were designed.

36:36 Very, very different.

36:37 So it's a lot more work on the driver developers to have to go from, here's how the hardware works, to here's the API we had.

36:45 So the move over the last five or six years has been towards these lower-level graphics APIs like Metal, DirectX 12, and Vulkan.

36:55 And these are considerably lower-level.

36:59 Just as an example, to get a triangle on the screen in DirectX 11, it's maybe 300 lines of code.

37:04 In OpenGL, it's maybe 100, if that.

37:07 To do it in Vulkan, you're easily at 1,000, just getting a triangle on the screen.

37:11 Really?

37:11 I was already feeling bad that it was 300 in DirectX.

37:14 And I can just remember the OpenGL code.

37:17 Set the scale.

37:18 Set the transform.

37:20 Set the viewport.

37:21 All of those things.

37:23 It's not easy programming type of work.

37:25 So Vulkan is even lower than that, huh?

37:27 Right.

37:28 Vulkan and DirectX 12 are really your lowest level.

37:31 But DirectX 12 is just Windows.

37:33 And with these APIs, you're able to utilize so much more in terms of what your GPU is capable of.

37:40 But you have to manage a lot more.

37:42 And that's part of why even the 3D engine and that switch in the back end is taking as long as it is.

37:47 Because the driver developers do a lot less for those APIs.

37:52 As an example, in DirectX and OpenGL, you can say I need a texture and load it with data.

37:57 And that's it.

37:59 And you can do it as many times as you want.

38:00 And Vulkan and DirectX 12, there's a max number of times you can do that.

38:04 I think the low number is maybe 4,000 allocations.

38:08 So it's up to you to instead allocate one big block, manage it yourself, and not keep doing that, as an example.

38:15 Right. You end up with those sort of maps, right, where this square is the actual whole picture or something else.

38:21 But to the right of it might be some other thing that you load all into one texture and you viewport into it or something.

38:28 Yeah.

38:29 Yeah, that doesn't sound fun.

38:30 It could be fun, but also you pull your hair out.

38:36 Another one of the things that the new APIs have changed is actually having to synchronize between the GPU and CPU and DirectX and OpenGL.

38:43 When you swap the buffers, execute this draw, whatever you're doing, your main loop where you're doing that, you don't have to wait until it's finished.

38:52 It's automatically synchronized between the GPU and CPU.

38:54 I see.

38:55 With the new APIs, that's not the case.

38:57 You typically, you have to actually add in barriers and fences between the different operations and just a lot of stuff.

39:03 You typically have more than one frame processing at a time.

39:06 You can actually utilize multiprocessing, which is a problem right now with Python because of the GIL.

39:12 So even though Vulcan has that, you can't really utilize it yet.

39:15 Maybe the no GIL stuff will gain traction in it.

39:18 It won't be a problem anymore.

39:20 One can hope.

39:21 So when I'm looking at this Vulcan page here, I see Windows, Switch, Stadia, Linux, Android.

39:26 I don't see macOS.

39:28 Is it still support Mac or what's the story there?

39:31 So the Molten VK is a layer on top of metal so that you can use it for Mac.

39:38 It's not directly supported.

39:41 You know how Apple is.

39:42 You got to use Objective-C.

39:43 They don't want you using C++.

39:45 It's not as supported.

39:46 It's the same thing.

39:47 They deprecated OpenGL.

39:48 And as of right now, there is no direct support for Vulcan.

39:51 So Molten VK is the...

39:53 See, it's like an intermediate layer between metal and Vulcan.

39:56 Right.

39:57 Talk about possibly leaving metal in.

39:59 Yeah, we...

40:00 As a support.

40:01 It's a possibility too.

40:02 Leaving...

40:03 It breaks your perfect abstraction though.

40:06 Yes.

40:06 Right.

40:07 What are you going to do though?

40:09 Pretty cool.

40:09 Metal's already doing that right now.

40:11 Some of the formats for the textures aren't supported.

40:13 That's a good point.

40:15 It's a little annoying.

40:15 Yeah.

40:16 Everyone's a snowflake over in the Mac world.

40:18 That is correct.

40:19 As I say on my Mac.

40:21 Okay.

40:21 Let's see.

40:22 One of the things I liked when I was looking through here is you've got a nice getting started tutorial.

40:27 Maybe we could talk just a little bit about just what the code looks like to get some stuff on the screen.

40:32 But you also have some video tutorials.

40:34 Jonathan, I know you put some of these together.

40:37 A while back.

40:38 They're a little outdated.

40:39 They're 06.

40:41 06.

40:42 Which is pretty old.

40:43 But we need to recreate them soon.

40:45 As someone who creates a bunch of videos.

40:47 They're very tricky to keep them in sync.

40:50 You can't just edit a few words or change a thing here.

40:53 It's different.

40:55 But yeah.

40:55 So people want to learn through the video style they can go through and watch some of these and get a sense of simple plotting or working with tabs and stuff like that.

41:05 Right?

41:05 Mm-hmm.

41:06 Yeah.

41:06 Most of the things are there.

41:08 Documentation still is a bit.

41:10 But with video tutorials and our read mirror, it's still a little bit lacking.

41:13 There's still some stuff that's undocumented that we're having to add.

41:15 But that's part of the point of the demo is you can see how all those, you know, most of the features are there and you can see how to code them.

41:23 Yeah.

41:24 But that's no excuse.

41:25 That's for us not in doing it for the docs.

41:54 I went to Toptal to hire a solid developer at a fair rate to help create those mobile apps.

41:58 It was a great experience and I can totally recommend working with them.

42:01 I met with a specialist who helped figure out my goals and technical skills that were required for the project.

42:07 Then they did all the work to find just the right person.

42:10 I had short interviews with two folks.

42:13 I hired the second one and we released our apps just two months later.

42:17 If you'd like to do something similar, please visit talkpython.fm/Toptal and click that hire top talent button.

42:26 It really helps support the show.

42:27 That's true.

42:28 That's true.

42:30 But also contributing to the docs and contributing to a tutorial or something like that.

42:35 That's also a good way for people to contribute.

42:38 That's a very good way.

42:39 Are you all open to having contributors and PRs and other things along those lines?

42:43 Apps.

42:44 Yeah.

42:44 I had a bunch of PRs and welcome to join the Discord.

42:48 We're in there all the time talking to people about when they're working on different spots in the API.

42:52 The problem is, you know, most of the users are Python users and libraries written in C and Objective-C and things like that.

42:59 So it's just a little bit of a disconnect there where a lot of users would like to help.

43:03 And when they go over to the library and see it's that, they go, oh, right.

43:06 You know what?

43:06 Actually, I wanted to work on a Python project.

43:08 We have this problem in a lot of the very popular places.

43:11 People want to contribute to Python itself.

43:13 And often that means C, not Python.

43:16 And darn it.

43:17 People want to contribute to Jupyter.

43:19 But a lot of times that means JavaScript, not Python.

43:23 Like, oh, come on.

43:24 But yeah, that's kind of what it means to build tools sometimes.

43:27 You guys have the demo fired up on your screen here.

43:31 Maybe you want to just talk us through a couple of the highlights and how we get this thing going.

43:36 Sure.

43:37 Got to keep in mind that not everyone can see what we're seeing.

43:39 So you can see the demo.

43:41 And we modeled this after GUI's demo and some of the other demos we saw of people doing similar things where you can see all the different features.

43:49 So if I pip install DeerPyGUI, is there just a command I run to just get this going?

43:53 It's one of the modules.

43:55 You have import DeerPyGUI.deerPyGUI.

43:58 And then you have import DeerPyGUI.demo.

44:00 And there's just one command show demo.

44:01 So you could even do that from a REPL if you wanted, right?

44:04 Yeah, you can.

44:05 And do that right away.

44:07 So you can kind of see a lot of different widgets.

44:09 Just your typical UI widgets that you have.

44:11 Yeah, go back to the widgets real quick for a sec.

44:13 Yeah.

44:14 So you've got a lot of nice ones.

44:15 You've got buttons.

44:16 You've got checkboxes.

44:18 You've got radio buttons.

44:19 You know, like you can only select one versus checkboxes.

44:22 You've got drop-down combo boxes, text, text with placeholder hint, I guess.

44:29 One of the areas that you have a lot of UIs around is the slider, what do you call them?

44:35 Slider float, slider ints.

44:36 It's like a thing that has a number, but then as you slot, you can not just type in it, but

44:41 you can drag it around and actually scale it.

44:43 I see this a lot in the Adobe Tools Audition.

44:47 You can go on if you want to change something.

44:49 You can click on a number and just move the mouse instead of typing to the number.

44:54 There was a lot of these other things because, again, this is really meant for a lot of 3D

44:58 engines and content creation.

45:00 A lot of color maps and things like that.

45:04 Let's see what else.

45:05 Text input, a lot of stuff here.

45:07 And remember, I told you a lot of the back ends are the same exact numbers, so you can get

45:10 things automatically like this.

45:12 All of these are linked together.

45:13 All right.

45:13 So what you're doing, there's like three text boxes, one that's plain text and two that

45:18 are passwords.

45:19 And as you type in one, they all, it's not real practical for passwords, but as you type

45:23 in one, it'll show you in the different locations.

45:26 So we're showing different flags, just different flags.

45:29 Yeah.

45:29 How do you create that binding between them?

45:31 Is that...

45:31 Well, that's what I'll tell you.

45:32 There is no actual binding.

45:34 They're truly the same value underneath.

45:36 Whenever you go to create this, let's say you call this item password one.

45:40 And when you go to create the second one, you can specify a source as password one, and

45:44 it will just, rather than have its own value, it will just truly use a pointer to the other

45:49 one.

45:49 And that's why all these...

45:50 Yeah, yeah.

45:50 That's really cool.

45:51 So that's how they stay in sync is...

45:52 Yeah.

45:53 Because they just, they are the same data.

45:54 Yeah, exactly.

45:55 It's free.

45:55 It doesn't cost anything.

45:56 There's no callback that has to run.

45:58 A lot of basic, simple plots for just pretty simple stuff.

46:02 Let's see.

46:03 Again, these are linked in the same way.

46:05 Okay.

46:05 Yeah.

46:06 Yeah.

46:06 Yeah.

46:07 So I encourage people, if they want to think about this framework, is create a virtual environment, pip install Geopi GUI, and then do the import command to

46:16 run the demo.

46:17 Yeah.

46:17 Yeah, really.

46:18 Date pickers.

46:20 But some of the cooler ones that, you know, you want to see, I mean, I can show these.

46:23 These are all pretty typical on most UI libraries.

46:25 I don't know.

46:26 Some of the ones...

46:27 That's on the knobs.

46:28 That's true.

46:29 Some of the ones, I guess, we have a table API, which...

46:33 Oh, that's nice looking.

46:34 Pretty cool.

46:35 You're able to...

46:37 These examples are just showing text, but you can put any widget.

46:39 You can put plots.

46:40 You can do all kinds of stuff.

46:42 So, yeah, with the table one, probably, if people think about it, like, it probably would

46:46 be called a grid in a lot of frameworks.

46:48 It's kind of a read-only Excel type of view, but very colorful and nice.

46:53 These aren't read-only.

46:54 These can be any widget you want.

46:56 They're more layout.

46:57 Oh, so you can put, like, a graph in one of the cells?

47:00 Yeah, you can put a plot.

47:01 You can put a node editor.

47:02 You can put anything you want in these.

47:04 It's best to think about a table as more or less a layout, essentially just giving you

47:08 columns of rows where you can put anything in it.

47:10 Oh, yeah.

47:11 Okay.

47:11 That makes sense.

47:12 Yeah.

47:12 And you can see here, this sorting one, you can kind of see.

47:15 You've got a checkbox in here.

47:16 I think there's an input at different things.

47:18 Tables, school, like I said, there's tons of plots.

47:21 Yeah, there's lots.

47:22 Anyone wants to put in the mouse.

47:24 And we have that example that you saw in there.

47:26 Oh, yeah.

47:27 You even have that detail, high-level and the detail graph in there.

47:31 That's cool.

47:32 Do you have trees?

47:33 We do.

47:34 Stuff with textures and the high-performance flip stuff.

47:38 The, for those that haven't seen, where's that?

47:40 The node editor.

47:41 So, those that are unfamiliar with that, I ran out of room here.

47:46 You know, this is for these node editors.

47:48 That node editor is exactly what I expected.

47:50 So, you've got these three little boxes with different bits of information or graphs, and

47:54 you just drag and connect them.

47:55 And, yeah, that's fantastic.

47:56 And you can put any widget in the library in these.

47:59 So, it's not limited to just, you know, a small subset.

48:01 And then, again, with the drawing API, your typical stuff that you're used to and other

48:06 drawing APIs, being able to draw a line, a box, a cube, things like that.

48:09 And then, also, some support for a lot of 3D operations, things like perspective divide

48:16 and depth clipping and all that to help support these type things.

48:19 Let's maybe round out our conversation here by talking a bit about, just give us a sense

48:26 on what it looks like to write some code.

48:29 So, there's not, I'm guessing there's not a graphical designer type of thing, like Xcode

48:35 storyboard or whatever.

48:36 We're not big fans of those.

48:37 Yeah.

48:38 You do this through code.

48:39 Yeah.

48:39 You build up your UI through code and layout elements.

48:42 Right.

48:42 Just give us a sense of how do I get, like, a text box and a button or something on the

48:48 screen.

48:48 What does the code story look like?

48:50 We talked about the 100 lines of OpenGL or whatever.

48:53 So, pretty much every DPG app, you just import DPG.

48:57 We do it as DPG most of the time.

48:59 From there, you'll create a context, which basically sets up the I'm GUI context, sets up

49:05 I'm nodes, sets up our internal context with all the different settings and state.

49:09 Oftentimes, these lower level frameworks, they have to go and get some context from the

49:14 graphics card itself and, like, get that from the operating system.

49:17 And I'm sure that kind of wraps that stuff all up.

49:20 Absolutely.

49:20 And then from there, you typically create the viewport.

49:23 And again, that's platform specific.

49:25 On Win32, we're using Win32.

49:27 We're using X11 on Linux.

49:29 And on Map, we're using Carriover or whatever it is.

49:32 We'll touch that one in about a year.

49:34 You got it working.

49:35 And there you decided to stay away from it.

49:37 Got it working and walked away from it for a while.

49:39 So, the viewport is basically like an empty window?

49:42 Right.

49:43 It's your actual operating system window.

49:45 Got it.

49:46 We call it a viewport.

49:47 And from there, you can create something like a window.

49:50 There's these root objects.

49:51 A window is like the I'm GUI window that you see below.

49:54 The blue window that you would see on a demo, things like that.

49:57 floating windows within the main viewport.

49:59 From there, to just add something like a text widget, it's dpg add text.

50:03 dpg add button.

50:04 dpg add input text.

50:06 Whatever the widget is.

50:08 And you can impose the hierarchy of parent-child relationship with context managers kind of the way that you could just use.

50:16 If I'm going to create a window, one of the windows, one of multiple possible windows, instead of creating a window object and say window add this or that, you would create a context manager and just do a bunch of ads.

50:26 Because.

50:27 Then it all just goes to that window.

50:28 Right.

50:29 Again, we're not object oriented, which kind of also sets us apart here.

50:34 If you weren't using the context manager, that same operation would be dpg add window.

50:39 And it returns either an ID or you can put the ID in with the keyword tag equals whatever your ID is.

50:46 Then you would push to the container stack.

50:49 And then when you're done adding items, you pop it back off.

50:52 The context manager handles that for you.

50:54 Right.

50:54 So it's adding the window, pushing it and popping it.

50:57 And if you wanted to do something, like I said, it's not object oriented.

50:59 So when you do add button, you don't get a button back.

51:01 You get a handle to internal button.

51:04 And then you use that handle and you can store it.

51:07 Just say B equals dpg add button.

51:09 And then all the various commands, you would use that handle to control it.

51:14 If you want to say, get the checked state of a checkbox.

51:18 Right.

51:18 Get value.

51:19 Yeah.

51:20 Or configure everything you did when you created it.

51:22 When you started off, you can modify later on using configure item.

51:25 And then you just pass in that handle and go from there.

51:29 Cool.

51:29 Is there an event loop type of thing?

51:32 There is.

51:33 So after you've created the viewport and you add your widgets, you would do set up Deerpy GUI.

51:39 And what that runs is that starts up the second thread.

51:42 We have two threads.

51:42 We have the rendering thread running.

51:44 And then we have a callback thread where all the Python's at.

51:47 So that's what set up Deerpy GUI does.

51:48 Show viewport actually shows the viewport and starts basically the platform specific event loop.

51:54 From there, start Deerpy GUI.

51:56 That is your event loop.

51:57 If you actually want to see the event loop, you would just do while is Deerpy GUI running, render Deerpy GUI frame.

52:04 Right.

52:04 And you could do everything you want inside of there.

52:07 And then when you're completely done, you destroy the context.

52:09 Looks super straightforward.

52:11 One thing that I don't see here is the callbacks.

52:15 So like when the slider slides or the button clicks, is there some way to hook that action?

52:20 Like obviously the save button is going to need some.

52:22 Yep.

52:23 It's a callback.

52:24 It's a keyword for callback.

52:27 And basically it can have three arguments.

52:29 The sender, which will send you the ID of the item that called the callback.

52:32 The second one is app data, which for us that can be either the value or if the callback's related to window resizing, it'll be the new size.

52:42 It's just data that DPG sends you.

52:44 And then the third argument, user data, is user can pretty much put anything they want, then it'll get passed through.

52:51 And it's useful for a lot of people that are creating OFB wrappings around the library.

52:55 Yeah, nice.

52:56 Is there one callback that handles all the events and then you do like a switch statement?

53:01 It's really up to the user.

53:02 You can have a different callback for every one or you can have one master callback where you just check the sender and do different operations based on what called the callback.

53:11 You have a little bit of freedom there.

53:12 We do have callbacks you can attach to inputs such as the mouse or the keyboard or the window resize.

53:20 Like you mentioned, we have callbacks to set up.

53:21 It is nice to be able to say, when this button gets clicked, do this.

53:26 And that makes it real simple.

53:27 But there's also times that you might want to, I want to capture all the button clicks and then do some common thing regardless of which button gets clicked.

53:34 It's nice to have that flexibility to go either way.

53:37 That's the biggest thing.

53:38 We try to be as flexible as possible and allow really geared towards a lot of people wanting to wrap and create their own kind of interfaces.

53:44 So there's a lot of freedom.

53:46 So I noticed that you have this, you call it the viewport, this like window that comes out of the operating system.

53:53 And then the DeerPy GUI windows live in that space.

53:57 Is there a way to simulate it looking almost like the DeerPy GUI window is the whole thing?

54:02 Could I not show the title bar of the one window and then maximize the inner window to fill it?

54:09 You can undecorate the viewport.

54:11 There are settings for that.

54:12 And then we have a command that's set primary window and you can basically set one of the, whatever I'm doing, one is the primary one and it'll fill the whole viewport.

54:20 And you get that.

54:21 But you can't necessarily move them.

54:22 When you do that, you can't have multiple viewports at the moment.

54:25 We're still working on that.

54:27 Is there like modal dialogues and that kind of stuff in there?

54:30 There is modal dialogues.

54:32 There is file dialogues.

54:34 A lot of people still tend to just import to Kenter and use their file dialogue because a lot of people don't like ours.

54:39 It's right.

54:40 The context menus.

54:42 Yeah, it looks great.

54:43 Like I said, people who are possibly interested should check out the gallery on the GitHub page.

54:48 That's a good litmus test of what does it look like if you want to use it?

54:51 I think it looks pretty good.

54:52 I like it.

54:52 Sure.

54:52 We're getting close to the end here.

54:54 One thing, we talked a lot about the future stuff already.

54:57 Maybe we don't really need to go into that.

54:59 We've got the Vulkan backend, the 3D engine and stuff like that.

55:03 One of the things that I always want to do with a GUI is put it into my taskbar or put it into my macOS dock.

55:10 And I want to be able to give a binary thing to a user and not tell them about virtual environments and pip install and all that.

55:16 What's the deployment story about giving somebody a distributable version of this app?

55:21 So a lot of users have used some of the tools, Pi, Pi 2.

55:26 Like Pi Installer or Pi 2.

55:28 Things like that.

55:29 Yep.

55:29 We did early on when we first started the project, had a batch file and some batch files that packaged it up for you.

55:37 Actually created the executable and everything so we could hand them around here, embedded the Python interpreter and everything.

55:42 We did remove those, but we do eventually plan on adding back.

55:45 So we really don't like having dependencies on other libraries.

55:48 So even though you are using that now, we would like to bring back that.

55:51 It wouldn't be that hard.

55:52 We already do that.

55:53 When we develop it, we are using an embedded version of Python and an executable.

55:57 We're not actually using this.

56:00 What is it?

56:01 This utils.

56:02 And we're not using any of that.

56:03 We're actually just using the Python C API directly and embedding it.

56:07 Yeah, just as a sidebar, one of the things I really think would benefit Python as a community is if there was just a built-in Python-M package or build executable or whatever.

56:20 And out the other side comes a .app, a binary Linux app, or a .exe.

56:26 And you just hand it out, right?

56:27 There's so many scenarios where people would like a tool that they would like to be able to share.

56:31 I feel like it's a bit of a chicken and egg thing.

56:34 People aren't doing that very frequently.

56:36 So why do we need that feature?

56:38 Well, they're not doing it because it's so super hard and fragile, right?

56:41 If it were as easy as pushing a button, I think maybe people would do it more.

56:45 So I don't know.

56:46 Anyway.

56:46 Absolutely.

56:47 That was one of the original reasons for our engineer sandbox project way early on is we did do the tools in Python, but we couldn't hand them to people.

56:54 We had to tell them, we got to install Python and then pip install this.

56:57 So the idea of that one was we were able to just hand them that.

57:00 A little bit wrap up on the audience side.

57:02 Mr. Hypermagnetic once again says, very nice design and similar to small JS libraries.

57:06 Yeah.

57:07 Nice.

57:07 Appreciate it.

57:08 Looks good.

57:08 Last thing.

57:09 I always am interested how these projects gain traction, how people find time and energy to put into them.

57:16 And one of the ways is for companies that use them or people that use them to sponsor you guys.

57:22 So you guys have a sponsor option here, which is part of the GitHub sponsor story, right?

57:29 We have GitHub sponsors.

57:30 I think that's actually a pretty big deal because it used to just be like, oh, you put a PayPal donate button or something on there, which is fine and all.

57:37 This is an awesome feature that they, I guess, Microsoft added.

57:40 I assume that they're the ones that did it.

57:42 Yeah, it's pretty good.

57:43 We do have the GitHub sponsors open collected and buy me a coffee.

57:48 Yeah.

57:49 So this is a part-time project for you guys, not full-time.

57:52 It sounds like you're doing mechanical engineering work full-time.

57:56 And then also this both at work, but then also bringing it out to the community a little bit.

58:00 That is correct.

58:01 If it directly applies to something we're doing at work, a bug or something, we'll add it here.

58:05 But for the most part, it is at home at night, you know, after our families are in bed and working on it there.

58:12 A labor of love.

58:13 Awesome.

58:13 And it's great.

58:14 It's great to see more UI frameworks and more UI innovation in the Python space.

58:19 So thanks for doing that.

58:21 Now, before we get out of here, let me ask you all the final two questions.

58:25 If you're going to write some Python code, what editor do you use?

58:28 Typically PyCharm.

58:30 Yeah, pretty much PyCharm.

58:31 And then a notable PyPI package, something you've run across.

58:35 Like, oh, this is awesome.

58:36 People should know about.

58:37 Typically just numpy is about the only one.

58:39 NumPy is about the only one to use.

58:41 We like to reinvent the wheel.

58:43 Viewer dependencies.

58:44 Right on.

58:44 Anthony out in the audience says, I'm guessing, question mark.

58:48 Does DearPython GUI play nicely with third-party libs like Nutka, PyInstaller, and so on?

58:54 PyInstaller, I know it does.

58:55 Nutka, I do not believe it does.

58:58 And then numpy or anything that supports the buffer protocol, you can use in a lot of our functions.

59:03 Very nice work.

59:04 Final call to action.

59:06 People want to get started with DearPyGUI or maybe give back to it.

59:10 Sorry, and Anthony says, it was a statement, not a question.

59:14 Thanks, Anthony.

59:15 Nice.

59:16 Yeah, final call to action.

59:17 People want to get started with DearPyGUI.

59:19 What do they do?

59:20 Just pip install and run the demo on the readme.

59:23 You can also join our Discord server.

59:25 There's about a thousand.

59:26 Go through the reason.

59:27 Read the docs for sure.

59:28 Read the docs.

59:29 Contributing would be nice.

59:30 We're still in the middle of refactoring a lot of things internally, so it may be a little

59:34 hard.

59:34 But other than that, also just sponsoring really helps out, makes it worth it.

59:38 Jonathan, Preston, thanks for being here.

59:40 Appreciate it.

59:41 You bet.

59:44 This has been another episode of Talk Python to Me.

59:46 Thank you to our sponsors.

59:48 Be sure to check out what they're offering.

59:50 It really helps support the show.

59:51 Take some stress out of your life.

59:53 Get notified immediately about errors and performance issues in your web or mobile applications with

59:59 Sentry.

59:59 Just visit talkpython.fm/sentry and get started for free.

01:00:04 And be sure to use the promo code TALKPYTHON, all one word.

01:00:08 With Toptal, you get quality talent without the whole hiring process.

01:00:12 Start 80% closer to success by working with Toptal.

01:00:16 Just visit talkpython.fm/Toptal to get started.

01:00:21 Want to level up your Python?

01:00:23 We have one of the largest catalogs of Python video courses over at Talk Python.

01:00:27 Our content ranges from true beginners to deeply advanced topics like memory and async.

01:00:32 And best of all, there's not a subscription in sight.

01:00:34 Check it out for yourself at training.talkpython.fm.

01:00:37 Be sure to subscribe to the show.

01:00:39 Open your favorite podcast app and search for Python.

01:00:42 We should be right at the top.

01:00:43 You can also find the iTunes feed at /itunes, the Google Play feed at /play,

01:00:49 and the direct RSS feed at /rss on talkpython.fm.

01:00:53 We're live streaming most of our recordings these days.

01:00:56 If you want to be part of the show and have your comments featured on the air,

01:01:00 be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:01:04 This is your host, Michael Kennedy.

01:01:06 Thanks so much for listening.

01:01:07 I really appreciate it.

01:01:08 Now get out there and write some Python code.

01:01:10 I'll see you next time.

01:01:11 Bye.

01:01:11 you you you you you you you you you you you you you you you you you you you

01:01:20 you you you you you you you you you you you you you you you you Thank you.

01:01:30 Thank you.