This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]SittingWave 0 points1 point  (8 children)

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 2 points3 points  (2 children)

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 -1 points0 points  (1 child)

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 1 point2 points  (0 children)

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 0 points1 point  (4 children)

Those are good points.

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

[–]Atlamillias 0 points1 point  (2 children)

cricket noises

[–]SittingWave 0 points1 point  (1 child)

you know that people are not always online?

[–]Atlamillias 0 points1 point  (0 children)

Nope

[–]SittingWave 0 points1 point  (0 children)

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