5 ms·

I'm a big fan of using wxPython instead of Qt or the other recommendations in OP. https://www.wxpython.org/ https://www.wxpython.org/ wxWidgets is mostly lice

I'm a big fan of using wxPython instead of Qt or the other recommendations in OP. https://www.wxpython.org/ https://www.wxpython.org/ wxWidgets is mostly licensed under an LGPL analog with linking exceptions intended to permit distributing binaries under any license you choose. No part of wxWidgets, including wxPython, has a license more restrictive than the LGPL.

pdonis 3y ago
I have tried wxWidgets and wxPython, and while there are many nice features, my issue with it has always been that its behavior is inconsistent across platforms. I have found Qt to be much better at delivering the same experience across platforms. Using PySide 2 with the previous version of Qt (Qt 5 instead of the current Qt 6) avoids any licensing issues since PySide 2 uses the LGPL version of Qt 5.
- LoganDark 3y ago
  > 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, rendered sizes of components, instead of the native components only being a skin over a secret other layer that has its own input handling (looking at you, Qt/GTK).
  - pdonis 3y ago
    > 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 quirks, I might as well just ship separate apps for each platform. It's been a while so I don't have specific examples, but that's generally what I remember running into. Of course a lot of this will depend on what specific things you are trying to do. 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. Qt has a built-in "widget", QSocketNotifier, to bring network I/O events into its GUI event loop, but wx does not, so I had to roll my own, and it took different tricks on different platforms to make it work (and it was still clunky even then). But many GUI applications don't have to do that.
    - LoganDark 3y ago
      > 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_communication https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_co... Or was wxWidgets 3 not out when you were playing with it last?
      - pdonis 3y ago
        > 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.
        LoganDark 3y ago
        > 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).

pdonis 3y ago

I have tried wxWidgets and wxPython, and while there are many nice features, my issue with it has always been that its behavior is inconsistent across platforms. I have found Qt to be much better at delivering the same experience across platforms. Using PySide 2 with the previous version of Qt (Qt 5 instead of the current Qt 6) avoids any licensing issues since PySide 2 uses the LGPL version of Qt 5.

LoganDark 3y ago
> 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, rendered sizes of components, instead of the native components only being a skin over a secret other layer that has its own input handling (looking at you, Qt/GTK).
- pdonis 3y ago
  > 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 quirks, I might as well just ship separate apps for each platform. It's been a while so I don't have specific examples, but that's generally what I remember running into. Of course a lot of this will depend on what specific things you are trying to do. 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. Qt has a built-in "widget", QSocketNotifier, to bring network I/O events into its GUI event loop, but wx does not, so I had to roll my own, and it took different tricks on different platforms to make it work (and it was still clunky even then). But many GUI applications don't have to do that.
  - LoganDark 3y ago
    > 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_communication https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_co... Or was wxWidgets 3 not out when you were playing with it last?
    - pdonis 3y ago
      > 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.
      - LoganDark 3y ago
        > 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).