Live data from Hacker News

Hello Qt for Python

blog.qt.io

161–170 of 176 posts

Re: Hello Qt for Python

#161
post #44
post #25

Sadly, we still don't have the seamless UI building functionality Delphi had 15 years ago, allowing making a fairly advanced desktop app in a day. Jumping between Qt Designer and IDE back and forth is still an order of magnitude more complicated than it needs to be.

I just took a look at delphi. What’s so unique about its ui builder?

Delphi's UI designer pioneered two-way tools, meaning that any changes to the contents of a form/window are reflected immediately in code.

The general design is this: there's a code unit (.pas) and declarative UI property file (.dfm) for every form in your application. When you modify any published properties for any controls/components on the form via the object inspector, these modifications are stored in the .dfm file. Any changes to the controls/components on the form (adding a control, removing a control, renaming a control) are immediately reflected in the .pas code for the form. And, the code is not just generated code that you can't touch, it is code that you are modifying along with the IDE. You can jump back and forth between the UI designer and code editor with a simple F12 key press.

When an application is compiled, the compiler automatically bundles the .dfm files as resources in the resultant binary and streams the properties in during form instantiation.

Where this all really shines is with event handling. You can, for example, double-click a button on the form and the designer will drop you into the code editor with a fully-defined OnClick event handler all ready to go. This is because Delphi has the concept of default events for controls/components. For non-default events, you can do the same by double-clicking on the event name in the object inspector.

The other thing is that the UI designer is running real code in the background for controls/components, so the design-time environment mirrors the run-time environment, and control/component designers can interrogate the RTL to find out which state they are in, and act accordingly. You can also write custom property editors that allow for complex property editing in a nice interface.

Our product, Elevate Web Builder, works exactly like this for building single-page web applications. It's extremely productive and a very good fit for web applications because, unlike desktop applications, there's not as much risk of mixing back-end code into your UI code and starting to makes things messy.

The key is that you need a strongly-typed language to make this all happen, so I'm not sure how applicable any of this is to Python.

Re: Hello Qt for Python

#163
post #44

Earlier quoted context omitted.

I just took a look at delphi. What’s so unique about its ui builder?

Delphi's UI designer pioneered two-way tools, meaning that any changes to the contents of a form/window are reflected immediately in code. The general design is this: there's a code unit (.pas) and declarative UI property file (.dfm) for every form in your application. When you modify any published properties for any controls/components on the form via the object inspector, these modifications are stored in the .dfm…

Well hey now, python is strongly typed. Type declarations are just optional. :) just giving you grief.

That said, especially the custom property editors would make e.g. Xcode’s interface builder almost worth looking at. I’ve just given up on graphical designers at all—last I checked thy were all terrible with responsive design, which is ironic on an ide that claims to target a mobile platform.

Re: Hello Qt for Python

#165

Earlier quoted context omitted.

And doing your GUI with Tkinter, which has an API that fits incredibly well with Python is a problem because...?

I'm really pleased to hear you say that. Every time I have asked about Tkinter on here or SO I get "Tk is really old, you should be using Qt or blahblah". So I guess I start to doubt myself and think that the issues I am having are because I am such a noob I used this crappy old framework that no serious developer would. However I still find similar issues with Tkinter as I discussed above, I really didn't expect to…

yuck, for the sake of everything, please don't use tk for new apps. They don't support hidpi (except for a global scaling of the app which sometimes does not even works - makes quite a bunch of tk apps unusable). For some reason they don't feel smooth either on > 60Hz screen.

Re: Hello Qt for Python

#167

Why though? Is there some useful benefit that python offers over C++, or is it just another language support so that people more comfortable with Python could use it? If I were ever to write a desktop app, which one should I choose, given I'm equally comfortable with both languages?

Python is a much higher level language than C++, with all the problems and benefits of that.

Re: Hello Qt for Python

#168
post #153

Earlier quoted context omitted.

Why was this downvoted? It will setup exactly what was asked for. Specifically qt 5.9.5 with PyQt.

>>> You can just do `pip install PyQt5` now. >> How well does that work on OSX? > conda install pyqt Your comment, while presenting a potential solution to the original problem, did not make sense in context and went off in another direction entirely.

Did you miss that I was replying to simonh, and to be specific, to this part?

> I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.

Re: Hello Qt for Python

#169
post #104
post #14

Earlier quoted context omitted.

Retained-mode GUIs like Qt , wxWidgets, gtk, etc aren't intuitive. Try an immediate mode GUI, like my python bindings to nuklear https://github.com/billsix/pyNuklear

What is the difference between the two GUI modes?

https://youtu.be/Z1qyvQsjK5Y

Re: Hello Qt for Python

#170

This is like 10 years too late. This could have prevented electron.

People use Electron because of web technology and also the abstractions available there like React, not because any dynamically-typed language would've sufficed. In fact, Python is at a disadvantage here anyways because it's not async by default.

Python is really in the same category as JavaScript as far as being asynchronous is concerned.
Post reply on HN