Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello Qt for Python

blog.qt.io

Post reply on HN
Print view View original

41–50 of 176 posts

Re: Hello Qt for Python

#41

Post by StavrosK »

mherrmann wrote: post #27
ntoll wrote: post #26

FWIW I use PyQt5 in a code editor project I maintain. While all GUI frameworks have hiccups and smells to various degrees, Qt and PyQt5 has been, relatively speaking, the strongest UI framework I've encountered for Python. Why? Ease of development, cross-platform reach, "batteries included" (e.g. accessibility features, important for my project), friendliness of the API and breadth of features immediately spring to m…

Sorry to be spamming here but check out my https://github.com/mherrmann/fbs . It is literally the solution to your pain point.

Man, when a project is this useful, spam away. Thanks for this.

Re: Hello Qt for Python

#42

Post by opencl »

bitL wrote: 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.

Delphi is still around, as is the open source clone Lazarus. It's certainly not as popular as it used to be but still actively developed with people using it.

Re: Hello Qt for Python

#43

Post by fladd »

fladd wrote: post #37

Does anyone know of a Qt binding for Python that is actually pythonic (as in follows PEP 8)? Both PyQt and Pyside are just one-to-one wrappers that use C-style naming for everything. I find that really strange. The same holds for most other GUI libraries, like WxPython. It seems the only real pythonic GUI libraries are Tkinter and PyGobject.

Oh and Kivy of course!

Re: Hello Qt for Python

#44

Post by drb91 »

bitL wrote: 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?

Re: Hello Qt for Python

#45

Post by drb91 »

cup-of-tea wrote: post #11
veeti wrote: post #7

Earlier quoted context omitted.

Permissive license.

So PyQt5 is GPL. Practically speaking what is the point of a new permissively licensed library?

This seems easily googleable. Are you really completely oblivious as to controversy surrounding the GPL, especially as opposed to LGPL and ASL/MIT/BSD?

Re: Hello Qt for Python

#47

Post by Hamuko »

fooker wrote: post #6

What happened to PyQt? Also, the API does not seem Pythonic at all.

That's because Qt isn't a Python library. The API is made to be compatible with the actual Qt API, so you can write label->resize(800, 600); in C++ and label.resize(800, 600) in Python.

Re: Hello Qt for Python

#48

Post by Hamuko »

sevensor wrote: post #17
mherrmann wrote: post #12

Earlier quoted context omitted.

... with a more permissive licence (Qt for Python is LGPL, PyQt is GPL or $550 per dev commercially).

And it's generally worth it. PyQt has been great, and I find the messaging from Pyside a little offputting -- "finally, Qt for Python." Pyside, you weren't there when I needed you, and now you're back and you want to pretend like we don't have history?

When did you need it? Because PySide is not new.

Re: Hello Qt for Python

#49

Post by dragonwriter »

mherrmann wrote: post #39
fladd wrote: post #37

Does anyone know of a Qt binding for Python that is actually pythonic (as in follows PEP 8)? Both PyQt and Pyside are just one-to-one wrappers that use C-style naming for everything. I find that really strange. The same holds for most other GUI libraries, like WxPython. It seems the only real pythonic GUI libraries are Tkinter and PyGobject.

It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.

> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time.

Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to context switch between the idioms of the host language and the idioms of the foreign library.

Re: Hello Qt for Python

#50

Post by Drdrdrq »

roblabla wrote: post #22

I've always found Qt and Python (PyQt and PySide) to be a weird match. So many times did I end up with cryptic segfaults in the python VM due to some python object being collected "too early", creating a dangling pointer in the C++ world. This can happen if you forget to set the parent object, for instance. I know that those are things you have to worry about when you write C++, but when in the python world, you kind…

This just means that wrapper around C(++) code doesn't handle resources correctly. As you said, once inside Python you shouldn't care about object collection process. Nothing should lead to segfaults, in worst case you should get an exception about missing parent ref.
Post reply on HN