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

101–110 of 176 posts

Re: Hello Qt for Python

#101

Post by jimnotgym »

mixmastamyk wrote: post #98
jimnotgym wrote: post #95

Earlier quoted context omitted.

As I said I am not qualified to judge how hard this is, but: I don't really like working in an IDE, or need to. I am happy to design GUI components in a markup language, for the kind of use cases I am talking about. However would it not be possible to hide the complexities of managing a GUI in the framework/bindings so that the Python user just has to deal with "Someone clicked OK>Run this function" in as easy a way…

VB was easy because of shortcuts provided by the IDE. If you don't want one, QML is what you are looking for. Saw anvil and it looked interesting, aren't apps tied to its system however?

Yes, that is the (major) downside. The trade-off is extreme productivity.

Re: Hello Qt for Python

#102

Post by markroseman »

jimnotgym wrote: post #99
markroseman wrote: post #94

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…

Check out http://tkdocs.com to get started _properly_ with tkinter.

The blocking thing you can do in two ways. First, put your blocking stuff in another thread and do it there, and when it's done call back into the main thread to tear down the alert.

The other way, to play nice with the event loop, is to do something like:

   makemydialog()
   Tk.update_idletasks()  # process events so that the dialog shows up
   do_my_stuff
   teardown
If within do_my_stuff you can periodically call update() to process events, it'll give the appearance of being more responsive.

After you get a bit more experience with doing some GUI stuff, and if you want to have a more long-running GUI, it will become more natural to think of initiating everything in response to event handlers, as opposed to the batch model of running your program linearly from top to bottom.

Re: Hello Qt for Python

#103

Post by ntoll »

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.

Aha... thanks for the heads-up. :-)

Re: Hello Qt for Python

#104

Post by vram22 »

billsix wrote: post #14
jimnotgym wrote: post #2

I would love to hear more about this from the sages of HN. I really don't enjoy GUI development in Python. I am not a good enough CS to have the language to describe what is wrong, but I find it really hard to get Python GUI stuff to do what I want.

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?

Re: Hello Qt for Python

#105

Post by loeg »

traverseda wrote: post #72
stavros wrote: post #66

Earlier quoted context omitted.

What would you recommend to someone who wants to write Python desktop applications today? I've used wxWindows way back when, and I'd hate to use Electron. Would you go with Qt for Python, or PyQT? Also, what's PySide/PySide2?

Not OP, I've been very impressed with some enlightenment apps written using python. In particular: https://github.com/DaveMDS/egitu https://phab.enlightenment.org/w/projects/python_bindings_fo... Scroll down to "python projects using EFL".

I wouldn't use enlightenment/EFL for a new project today. If you've got the opportunity to greenfield, Qt is a much nicer framework.

EFL has a number of questionable design choices, covered a little bit here: https://what.thedailywtf.com/topic/15001/enlightened .

Re: Hello Qt for Python

#106

Post by jimnotgym »

markroseman wrote: post #102
jimnotgym wrote: post #99

Earlier quoted context omitted.

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…

Check out http://tkdocs.com to get started _properly_ with tkinter. The blocking thing you can do in two ways. First, put your blocking stuff in another thread and do it there, and when it's done call back into the main thread to tear down the alert. The other way, to play nice with the event loop, is to do something like: makemydialog() Tk.update_idletasks() # process events so that the dialog shows up do_my_stuff t…

You have told me more in that message than the whole book I read on Tkinter, and all of the experts who told me I was using the wrong framework. Thank you.

I guess looking at it, having a process that is going to take a few seconds and must block the user from progressing until it completes is perhaps not the scenario most tutorials envisage. Thanks again

Re: Hello Qt for Python

#107

Post by fernly »

kbumsik wrote: post #89
stavros wrote: post #66

Earlier quoted context omitted.

What would you recommend to someone who wants to write Python desktop applications today? I've used wxWindows way back when, and I'd hate to use Electron. Would you go with Qt for Python, or PyQT? Also, what's PySide/PySide2?

As you can see, Qt for Python is not yet stable release. So you will want to use PyQt5 first. I remcommand PyQt5 because there are more resouces available on the internet now. PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs are almost identical, so you should be able to switch to Qt for Python quite easily when it is stable. By the way, Qt for Python is re-branded from PySide2. They are…

Would it be as simple as a global change of all "from PyQt5" to "from PySide" in all import statements?

Re: Hello Qt for Python

#108

Post by fernly »

simonh wrote: post #62
mherrmann wrote: post #40

Earlier quoted context omitted.

You can just do `pip install PyQt5` now. That is possible without a virtual environment, but in practice I think you still want to use one: python3 -m venv venv && source venv/bin/activate && pip install PyQt5.

How well does that work on OSX? I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.

With Python3 and PyQt5 it is literally as simple as "pip install pyqt5". I speak from having built and maintained multiple PyQt-based apps on MacOS.

Edit: I should say, there are MacOS-unique difficulties if you want to bundle your nice PyQt5 script into a standalone MacOS app bundle using PyInstaller. But that's a separate issue.

Re: Hello Qt for Python

#110

Post by ageofwant »

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.

No it really is not. You are defending Qt's decision to keep their own lives simple. That's fine for Qt, but not so for their target Python audience.

Generating similar high quality docs for the Pythonic wrapper should not be a issue.

Isn't the point that you don't have to translate in your head all the time. For non-Pythonic, non pep8 code you are going to do that constantly, not only when you read the Qt docs.

pep8 is a subset of 'Pythonic', the current wrappers are not only not pep8 compliant, they are also un-Pythonic in other ways.

Don't get me wrong, I appreciate Qt trying to expand their user base, but I would consider this effort a early milestone on the road to something that really fits into the Python ecosystem.

Post reply on HN