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

Python GUIs

pythonguis.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Python GUIs

#41

Post by LoganDark »

pdonis wrote: post #37
LoganDark wrote: post #26

Earlier quoted context omitted.

> my issue with it has always been that its behavior is inconsistent across platforms Isn't that because different platforms are different? This should be a feature. "Cross-platform that feels native", because each platform has a different definition of "native". IME wxWidgets was always better than Qt or any other of the high-level piles of bloat. For example, its layout system would actually use the platform-native…

> Isn't that because different platforms are different? To some extent they are; I don't mind having Windows-native-looking widgets on Windows and Linux-native-looking widgets on Linux. But programmatically, code that is designed to do a particular function should do it the same on all platforms. That's the point of having a cross-platform toolkit. If I end up having to write a lot of platform-specific code to handle…

> If I end up having to write a lot of platform-specific code to handle quirks, I might as well just ship separate apps for each platform.

that's weird, wxWidgets' job is supposed to be to handle this for you.

> One item that I do remember having particular issues with was multiplexing network I/O with the GUI--which is inherently difficult because both of those things want to run their own event loop.

The UI always has to run on the main thread, so why not run the non-UI tasks in a separate thread and send events between the two to communicate? https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_co...

Or was wxWidgets 3 not out when you were playing with it last?

Re: Python GUIs

#43

Post by pdonis »

LoganDark wrote: post #41
pdonis wrote: post #37

Earlier quoted context omitted.

> Isn't that because different platforms are different? To some extent they are; I don't mind having Windows-native-looking widgets on Windows and Linux-native-looking widgets on Linux. But programmatically, code that is designed to do a particular function should do it the same on all platforms. That's the point of having a cross-platform toolkit. If I end up having to write a lot of platform-specific code to handle…

> If I end up having to write a lot of platform-specific code to handle quirks, I might as well just ship separate apps for each platform. that's weird, wxWidgets' job is supposed to be to handle this for you. > One item that I do remember having particular issues with was multiplexing network I/O with the GUI--which is inherently difficult because both of those things want to run their own event loop. The UI always…

> was wxWidgets 3 not out when you were playing with it last?

I don't think so, I think 2 was the latest version I worked with.

> why not run the non-UI tasks in a separate thread and send events between the two to communicate?

Sure, you can do that, if you're willing to deal with all the extra complications involved with having multiple threads and coordinating between them. For some applications that's necessary, but in many cases none of the events, either GUI or network I/O, require CPU intensive responses, so you don't need separate threads for performance, and having them all in one event loop makes the code a lot simpler.

Re: Python GUIs

#44

Post by maho »

moffkalast wrote: post #27
BlackLotus89 wrote: post #4

I sometimes miss the good old days of visual basic and delphi when I could create a gui that just worked in seconds, help pages via F1 and quick access to all events possible through simple gui clicks. A few days ago I tried getting a simple PyQtWebengine example working using pyqt6 and failed miserably. It was a frustrating experience for sure

Making a GUI these days that isn't based on HTML and CSS in some way is an... experience.

Making a GUI that is based on HTML and CSS and JS is also an... experience.

I have some (ancient) experience in RAD. Once per year I try picking up React/Vue/Angular or whatever is the current fashion, but I get stuck. It's just so _insane_.

Re: Python GUIs

#45

Post by [deleted] »

zzzeek wrote: post #2

for Python GUIs (or "TUIs", or "a screen with colorful buttons and controls I can use with the mouse or keyboard but NOT a "GUI" " if that helps some of the responders to get through the day) I recommend considering a console-based GUI using the excellent Textual: https://textual.textualize.io/ this is the most modern GUI (in a console or not) framework you'll find for Python right now.

[deleted]

Re: Python GUIs

#46

Post by Case_of_Mondays »

I have been looking at Python GUI libraries/frameworks/services over the past > 1 year. I'll cut straight to the chase with my recommendations for what they are worth.

- NiceGUI https://nicegui.io/#features - my favorite of the bunch, essentially wraps Quasar Vue components with accessible python. Tons of features including SPA, FastAPI under the hood, TailwindCSS. Have used it on a few projects and started contributing recently.

- Streamlit https://streamlit.io/ - if your goal is to get some python code set up with a GUI and deployed ASAP this is the best option. I have gone from 0 to a full working app in like an hour for some projects. Lots of love for it. A bit limited in terms of full-scale applications and large backend databases but it actually holds up really well.

There are a lot of other ones that people regularly recommend.

- Gradio https://gradio.app/ - really popular with huggingface and ml folks. Similar to streamlit in that it sacrifices some level of depth for speed of standing up projects.

- Textual https://www.textualize.io/projects/#textual - Building text-based UIs for the console. Seems to be pretty popular on reddit... Not to be a hater, but I have never seen a good argument for why it's worth dumping a bunch of time into this versus a web-oriented framework. They say "it's useful for products that don't need the internet", "you can use it through ssh", etc... doesn't really fit with my needs, I'll just leave it at that.

- Anvil https://anvil.works/ - a "low code" option for building python GUIs. I am pretty impressed, it has integrated databasing and a lot of plugins. If you are aiming for a scalable application for a large number of users this is probably a good options. My personal gripe with it is the number of mouse clicks it takes to do stuff but that could also be my lack of experience with the tool.

- Plotly dash https://dash.plotly.com/ - not usually thought of as a full GUI library necessarily but they have options for deploying the dashboards to the web - and the overall look and feel is nice. A good option if you have a small notebook with plots that needs wider accessibility.

My use cases are typically 10 - 50 users in an enterprise setting, so accessibility/low barrier to entry (pretty much meaning web-based) are concerns of mine. I also lean toward wanting to avoid learning overly-opinionated libraries (I put Qt and tkinter into this category). Why spend 50 hours learning Qt's way of building an app when I could use something like NiceGUI which lets you build a nicer looking app and gets you familiar with web dev concepts in the process. Imo a better use of my time.

Re: Python GUIs

#47

Post by LoganDark »

Nobody has recommended prompt_toolkit (TUI only) yet, so here I go:

https://python-prompt-toolkit.readthedocs.io/en/master/

I'm working on an interface for an LLM (large language model), and prompt_toolkit seems to be the only library with enough text-buffer features for me to implement everything I want.

It's quite imperative-feeling though. Have to keep references to individual widgets if you want to do anything with them later.

Re: Python GUIs

#48

Post by LoganDark »

pdonis wrote: post #43
LoganDark wrote: post #41

Earlier quoted context omitted.

> If I end up having to write a lot of platform-specific code to handle quirks, I might as well just ship separate apps for each platform. that's weird, wxWidgets' job is supposed to be to handle this for you. > One item that I do remember having particular issues with was multiplexing network I/O with the GUI--which is inherently difficult because both of those things want to run their own event loop. The UI always…

> was wxWidgets 3 not out when you were playing with it last? I don't think so, I think 2 was the latest version I worked with. > why not run the non-UI tasks in a separate thread and send events between the two to communicate? Sure, you can do that, if you're willing to deal with all the extra complications involved with having multiple threads and coordinating between them. For some applications that's necessary, b…

> Sure, you can do that, if you're willing to deal with all the extra complications involved with having multiple threads and coordinating between them. For some applications that's necessary, but in many cases none of the events, either GUI or network I/O, require CPU intensive responses, so you don't need separate threads for performance, and having them all in one event loop makes the code a lot simpler.

This is weird. Having the worker thread separate from the UI thread is a good separation of concerns regardless of whether you need the thread for performance or not. I don't remember if wxWidgets 2 even had message passing between threads, though.

I'd invite you to try wxWidgets 3, it seems to have changed a lot (for the better).

Re: Python GUIs

#49

Post by Case_of_Mondays »

pacifika wrote: post #12

The problem remains delivering the app to the customer in my experience, unless something like flatpak can be used cross platform. Unless picking a solution from the start and testing it throughout, I find that the most challenging.

I'll flip this around and ask (in earnest - not trying to be snarky), if things like streamlit, NiceGui, gradio, etc exist where you can build a web-accessible gui with only python... why would I ever use Qt?
Post reply on HN