3 ms·

> 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

by 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
      > 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. It can be, but it has a cost in code complexity. Sometimes that cost isn't worth paying. > I'd invite you to try wxWidgets 3 Yes, it sounds like it's worth me taking a look. I have a Python GUI package [1] that right now only supports Qt 5 in its latest version; it would be nice to put wx support back in. [1] https://pypi.org/project/plib3.ui/ https://pypi.org/project/plib3.ui/
    - pdonis 3y ago
      > try wxWidgets 3 Update from my previous post: I took a look at release dates and wxWidgets 3 was available as far back as 2013, so that is the version my comments were based on (wxPython's version 4 series is the latest that's based on wxWidgets 3, that version of wxPython is the latest I've tested with).

by pdonis 3y ago

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
    > 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. It can be, but it has a cost in code complexity. Sometimes that cost isn't worth paying. > I'd invite you to try wxWidgets 3 Yes, it sounds like it's worth me taking a look. I have a Python GUI package [1] that right now only supports Qt 5 in its latest version; it would be nice to put wx support back in. [1] https://pypi.org/project/plib3.ui/ https://pypi.org/project/plib3.ui/
  - pdonis 3y ago
    > try wxWidgets 3 Update from my previous post: I took a look at release dates and wxWidgets 3 was available as far back as 2013, so that is the version my comments were based on (wxPython's version 4 series is the latest that's based on wxWidgets 3, that version of wxPython is the latest I've tested with).