Not answering the real question but we have a lot of little wxPython GUIs driving big engineering design software suites at the advanced nuclear design company I work at. Engineers (mechanical, nuclear, etc.) can grasp it fairly quickly, get their knobs on the screen, and be back to doing their mechanical and nuclear engineering. We got started because the original python guy (me) learned it from a grad student in 2005 via the excellent wx docs and demos collection of examples. Works great and we recently went all Python 3.
Chandler is on that list! That's the failed PIM desktop software that Mitch Kapor financed as a hobby project and which was the subject of the book "Dreaming in Code"by Scott Rosenberg. Terrific book, shame about the software.
It's big in music and math for some reason; Maxima's main front-end is wx, GNUplot uses it, and a whole bunch of sequencers use it. Also the vanilla eMule and BitTorrent gui clients.
I read a while ago that Dropbox desktop clients are written in wxPython, and maybe on all of Windows, MacOS, and Linux. Don't have a citation right now.
Not sure if you meant only in wxPython or wxWidgets as well, but a big one that is mainly in C++ but also provides Python scripting is KiCad: http://kicad.org
I used (and liked) wx in the nineties - didn't know it was still around.
Qt is my goto GUI for Python these days, does anyone have experience with wx vs Qt for Python? The samples look like it's all dynamically generated (vs. something like QtDesigner) and that's how we used it way back when.
I agree that electron is a bloated resource hog. But if you're running a web browser anyway (I always am) then it's not a big deal to have a web app with the server running locally and the client being a browser tab.
Well sure. That is to say that Qt/Wx/GTK/etc. are as useless to cabalamat as to a Ukrainian plumber. In other words, that isn't saying much. If you don't write desktop apps, you wouldn't use a desktop app GUI toolkit, but that's a tautology. But cabalamat's comment implied that all desktop GUI toolkits are now useless because we have the web, which is a fallacy of generalizing personal experience to everyone else.
> But cabalamat's comment implied that all desktop GUI toolkits are now useless because we have the web, which is a fallacy of generalizing personal experience to everyone else.
Not useless in general, just useless for me
I once wrote a Python program to compile GUIs[1] -- you input a description of the GUI as a text file and it outputs Python code that implements the GUI in Tkinter. I dusted this off for a project last year but eventually decided that making it web-based would be easier to write, look nicer, and have more functionality.
Obviously if other people find WxPython useful, good luck to them.
games - I've considered writing a hex-based board wargame as a web app
document editor - my catwiki wiki software is this, I suppose
security focused software a la Keybase client - the last time I wrote security software was a zero-user-interface email encryption system. If I did something like that in future, any interface would be web based
the point is HTML5/CSS/JS nowadays provides superior UI experience to traditional UI frameworks. In many of the categories above, there are electron/webview based applications that's very popular.
The only thing superior about HTML/CSS/JS GUI are its ease of deployment and portability characteristics. As a UI platform, it feels like a huge step back from modern desktop GUI APIs, like we are doing UI programming in the 90s again.
And I feel the other way around. "Modern Desktop GUI" feels clunky and archaic to me :-) Like menus and toolbars and the "ribbon" ajd the status bar and those clunky desktop widgets...
That is a UI design issue: you don’t gave to use those, and if you do, it’s up to you to use them right. Web comes with a lot of limitations, many of those widgets obviously don’t make sense in the browser; heck they probably don’t make sense on the desktop but that is less obvious. With web, simplicity is enforced out of nescessary limitation, and this has turned out to be good for users.
From a programming perspective, modern desktop UI libraries are much more powerful and have less limitations. How you use that power is up to you and your UXD, however.
I've been programming computers since the time they came with two 5.25 inch floppies with green text monitors and have seen all UI paradigms since then. Maybe I have a right to have a point of view?
The standard desktop design paradigms were built by programmers for programmers - a lazy way to approach things leading to clunky to use software. The dog eat dog world of the web and rise of touch has forced us to turn to designers to play a huge role in simplifying interfaces and flows.
>The standard desktop design paradigms were built by programmers for programmers - a lazy way to approach things leading to clunky to use software. The dog eat dog world of the web and rise of touch has forced us to turn to designers to play a huge role in simplifying interfaces and flows.
UI design and HCI has been a thing for 4+ decades.
The web is a very poor example of those things -- not to mention it has forgotten decades of research and best practices.
Also, GUI toolkits were never fun or easy to use in desktop development. I've used MFC, wx and Qt with C++, Forms and WPF with C# and Qt with Python. All of those had their challenges so browser-based GUIs don't seem so bad as an alternative. Not a fan of JS but modern toolkits are almost at a point where they hide enough of the ugliness.
Also, GUI toolkits were never fun or easy to use in desktop development.
NeXTSTEP was fun. Frankly, its still easier to develop for OPENSTEP 4.x then the web. VB when it first came out was amazing and all the VBX control you could buy were amazing. Heck, even the Newton was a lot cleaner to build a UI which still amazes me since Javascript should have been capable of the same type of prototype-based interface.
Electron != web app. Have you tried using Slack's actual web client vs the Electron app? I personally strongly prefer the stand-alone client. The same with the git GUI client. The equivalent web thing is github.com.
If the original statement was "I prefer Electron for my desktop apps over Qt/Wx/GTK/etc." I could totally understand that. But the original comment was "My 'go to GUI' is a web app". That's not the same thing. It is our modern version of "when all you have is a hammer, everything looks like a nail."
It's not my experience. Appart from some chat apps and vscode, i have only bad xp with electron apps. Stuff like stremio or popcorn time are slow and the mix of web paradigms into the destop sucks. Using dropbox, office, mails clients, are way better on native than then web version.
I'm in my 50s but not trying to be stuck in my ways so this year my development goal is to learn web app development. Interestingly, I will learn it from my mentee, who's been doing a great job using browser-based GUIs for a fleet of test and production machinery. Guess I'm the mentee now...
49 here. Old c / c++ salt. Self taught go, js, and vue. I love it. Always fun to learn new approaches . After build reactive uis it will be hard to go back to building them the traditional way
It's been a long time since I looked at wxpython, but does it still have a wxWebKit or similar that you could use to wrap your web app into a local compiled executable?
Edit: at a computer, this would be wx.html2, but it's a wrapper for the native platform's browser components so would vary from system to system.
Rather what is the normal workflow for making UI in web-apps?
How do you keep the abstractions from leaking over?
It seems you need to keep all the CSS quirks in your head to be productive.
As a counterpoint in something like WPF, I do not need to know much or anything about XAML to produce a usable UI quickly that will not break in bizarre ways.
Same goes for PyQT, a few hours starting from scratch(ie not knowing anything about PyQT) and you can make something usable.
WxPython same thing, classes in a control such as wx.dataview look normal enough.
I haven't used wx but at least one of the advantages is when exporting a project to .exe I assume you don't need to include the Qt libraries (i.e. .dll files) separately to conform with their licence, it can (legally) be in a single executable.
Yes, that's an issue, but only if you don't want to make your Qt client Free Software. Since nowadays most client-side applications are tied to some web service anyway, releasing those as Free Software might even be advantageous.
Having said that, statically linked wxWidgets .exe files are usually smaller than Qt .exe files. Moreover, dynamically linking to Qt does have technical advantages for certain types of applications (mostly plugin architectures).
Shameless plug: You can create all variants (Qt or wxWidget, each statically or dynamically linked) very conveniently on your Linux build server via cross-compiling, which has become really easy thanks to the MXE project that I started in 2007.
The LGPL requirement is relinkability, which implies either distributing object files for your application (rare, inconvenient), or, more commonly, linking the LGPL library as a shared object. But that shared object could be stripped down to contain only the symbols your app uses (and their transitive dependants) — just as long as someone can do the same and use their API-matched .so as a drop-in replacement.
I tried Qt (in C++) and even though it's developing (QML brings "modern" mobile widgets) it felt like they are stuck in the nineties.
Heavily object-oriented code and custom scripting languages that are really hard to understand and use, and when there were problems (memory leaks, reference counting) I was stuck 15 (Qt) calls deep somewhere in the huge codebase.
Thanks, but I'm now doing it myself and learning the right abstractions (and sane software architecture in general), instead of spending my time learning the incantations to make this elephant move the way I need him to.
I work on a sizeable desktop application written in PyQt. While I agree that Qt has a very nineties feel about it, you don't have to buy into that. Specifically, you don't have to use class hierarchies to model your domain. It actually helps to have a language boundary -- we can let Qt be its object-oriented self, but on the Python side it's different. We do a limited amount of subclassing, which lets us hook into user interaction events, but other than that we use whatever works best in Python. As time passes, this seems to involve more and more straight-forward procedural code, less and less object-oriented modeling.
My experience as well - a lot of my nuts and bolts OO work in static languages was making things conform to interfaces and existing class hierarchies. In dynamic languages there's less need for that and hierarchies are shallower and less entangled. None of that is surprising, of course.
"Qt is Java for C++", one of my colleagues used to say, and I saw what he meant once I started working with it. We used to develop with Qt4 a lot and I rarely ran into any issues at all, getting started was really straight forward and the documentation and examples are (were?) pretty comprehensive.
Nice, but I find the release announcement a bit underwhelming. Which of the seemingly minor fixes and tune-ups does warrant such a major version bump ?
I glanced at the information and, if I understand it correctly, 4.0.0 is the first release of a ground up rewrite.
What's not immediately clear (and perhaps because I did not read the material clearly enough) is if any significant features were added. I wonder because I find it hard to rewrite something without taking advantage of the opportunity to add features. Or perhaps the desire to add features that would be difficult with the 3.x.x code drove the upgrade.
Great work! Finally a stable version working with Python3!
I find wxPython highly productive and enjoyable to work with and the wx C++ documentation has always been outstanding. Now the Python docs are also really good! https://docs.wxpython.org/
I know that Qt gets most of the publicity, but personally I prefer wx (having written huge applications in wx and only a small one in Qt, but still). Being able to .Bind() anything without sub-classing and the fact that the class constructors normally takes sensible parameters so that no further method calls are needed to set up a widget makes it very fast and compact to generate dynamic UIs with readable code.
The work Robin Dunn has done with wxPython is simply massive and he should be known as one of the great open source legends, especially in the Python community! Congratulations on a fantastic release!
Does wxWidgets provide any declaration based reactive programming with data binding? Something like WPF/XAML or Qt/QML or any modern web framework provides? Once you use a modern GUI framework with reactive programming capabilities, it is hard to go back to writing the code line by line procedurally to create your GUI and to keep the information on screen up-to-date without using reactive elements.
Unfortunately they decided to pull all the 3.x versions from pypi/pip at the same time, breaking a lot of projects that use pip to install dependencies but haven't yet ported to the new wxpython. I don't really understand why anyone would do that, but eh.
Lesson #1 in why developers shouldn't be unilaterally in control of the packaging & distribution and why I hate "wild west" style package repositories.
I wonder if it makes more sense e.g. for macOS to create a Swift UI and an existing python code base as external process which is called on request.
Does somebody knows which API interface specification is most suitable for that kind of communication on a single PC: Swift <-> Python ? For web it easy (e.g. REST) but there has to be other options on a fully controllable code base on your PC (seems my desktop programming days are long gone.. otherwise I would know myself)
For me, this difference made web UI frameworks much more approachable. Visual widget catalogs simplify the task of finding widgets or code samples. Widget screen shots help determine if code is performing as expected.
Sadly, the screenshots on that page seem to have been last updated when Windows XP was still current (which was 10+ years ago)
They're also not HiDPI/Retina, and the whole website design seems to be stuck in the mid-2000s, too. Somehow mobile and web developers got aboard all the new design and interaction trends, but Desktop GUI frameworks seem to be all stuck 10 years behind.
If I had to guess, I'd say it's probably because of a lack of capital investment in desktop software.
And yet a lot of people don't understand why everyone is using Electron for desktop apps these days.
Indeed this is a very very old library and wx has existed for a long time. I think many of the existing GUI have been ported to or started out with Qt. I did a project using WxPython before, while it was much more pleasant than Qt (it was around 2011), the GUI felt really old. After that, I switched to Qt for another project due to the size of community support and the features available in Qt.
Either way, at least in my experience, I had to look up the C++ documentation because the Python binding documentation was never complete.
> Somehow mobile and web developers got aboard all the new design and interaction trends
Because the new design trends are all about how to adapt to the limitations (and possibilities) of mobile and web. For desktop applications these mobile-first designs don't work very well (see Windows 8) and we already had long-established design patterns that do.
I have been using wxpython on and off for last a few years, the nice thing is it gives a natural looks on each supported OS, so your application won't standout as odd/fancy/weird/off, as with some other cross platform GUI framework do;
This brought a couple of app ideas back to the front of my mind, but also the difficulties involved in shipping a Python app to an end user. Requiring the user to care about the right version of the runtime, their python and library path, etc. is a real pain in the ass for all concerned.
Are there any Python projects out there that allow you to ship a "binary" (even if it's just a self contained python with the relevant libraries like WxPython brought in) for people to use?
They are shipping Python 3.5.2 + required PyQT5 parts + other python libraries. Only Python files visible for users are in plugins folder (rest are bundled[as pyc-s] in single zip file, python interpreter is "merged" with entry *.py file as an executable).
You can easily download Cura from Ultimaker site and "inspect" result yourself ;)
My biggest problem with wxpython is that you apparently can't set closures as event handlers. Instead, you have to define a member function, and register it. This makes the process a bit tedious compared to JavaScript.
It also allows the direct binding of events to:
* A handler method in the same or another object.
* An ordinary function like a static method or a global function.
* An arbitrary callable object.
If it works for arbitrary callable objects it should certainly work for closures.
84 comments
[ 2.4 ms ] story [ 148 ms ] threadIt is tested against Python 3 in their Travis config: https://github.com/wxWidgets/Phoenix/blob/master/.travis.yml
https://webcache.googleusercontent.com/search?q=cache:ght2vB...
Out of curiosity, any big or important software written in WxPython?
As you can see much of the list is either 'toy' applications or older applications that haven't been updated for ages.
Qt is my goto GUI for Python these days, does anyone have experience with wx vs Qt for Python? The samples look like it's all dynamically generated (vs. something like QtDesigner) and that's how we used it way back when.
It's unlikely that cabalamat would attempt making most of those and the others could definitely be done as a web/electron app if desired.
But probably shouldn't because we don't produce enough renewable energy yet. There's still something to be said about using TRUE native apps.
Not useless in general, just useless for me
I once wrote a Python program to compile GUIs[1] -- you input a description of the GUI as a text file and it outputs Python code that implements the GUI in Tkinter. I dusted this off for a project last year but eventually decided that making it web-based would be easier to write, look nicer, and have more functionality.
Obviously if other people find WxPython useful, good luck to them.
1: see https://github.com/cabalamat/parrot
I'd write a web app and expose it on 127.0.0.1:someport rather than electron (which is bloated). Going down IgorPartola's list:
Text editor - I'd probably make this terminal-based using curses. Then I could easily use it on a remote server I'm ssh'd into.
video, audio editor - I've no plans/desires to write anything like these
system widgets and settings - a web app is highly suitable for editing system settings
web browser - far too big a project for me!
terminal emulator - plenty of good ones around already. I mostly use KDE's konsole.
git GUI client - I've recently been adding some git functionality to my catwiki wiki software (a web app) https://github.com/cabalamat/catwiki
crypto coin wallet - web app
chat client - web app or terminal-based
games - I've considered writing a hex-based board wargame as a web app
document editor - my catwiki wiki software is this, I suppose
security focused software a la Keybase client - the last time I wrote security software was a zero-user-interface email encryption system. If I did something like that in future, any interface would be web based
Text editor, document editor -> VS Code/Atom
terminal emulator -> Google's terminal emulator
git GUI client -> GitHub client is electron based
chat client -> slack is electron based
games -> lots of web based
From a programming perspective, modern desktop UI libraries are much more powerful and have less limitations. How you use that power is up to you and your UXD, however.
The standard desktop design paradigms were built by programmers for programmers - a lazy way to approach things leading to clunky to use software. The dog eat dog world of the web and rise of touch has forced us to turn to designers to play a huge role in simplifying interfaces and flows.
UI design and HCI has been a thing for 4+ decades.
The web is a very poor example of those things -- not to mention it has forgotten decades of research and best practices.
What it has is just ubiquity and easy access.
Agree with your opinions, though, you old fart.
NeXTSTEP was fun. Frankly, its still easier to develop for OPENSTEP 4.x then the web. VB when it first came out was amazing and all the VBX control you could buy were amazing. Heck, even the Newton was a lot cleaner to build a UI which still amazes me since Javascript should have been capable of the same type of prototype-based interface.
If the original statement was "I prefer Electron for my desktop apps over Qt/Wx/GTK/etc." I could totally understand that. But the original comment was "My 'go to GUI' is a web app". That's not the same thing. It is our modern version of "when all you have is a hammer, everything looks like a nail."
No. I've written GUI software, and tools for building GUI software[1], in the past.
1: https://github.com/cabalamat/parrot
Edit: at a computer, this would be wx.html2, but it's a wrapper for the native platform's browser components so would vary from system to system.
Rather what is the normal workflow for making UI in web-apps?
How do you keep the abstractions from leaking over?
It seems you need to keep all the CSS quirks in your head to be productive.
As a counterpoint in something like WPF, I do not need to know much or anything about XAML to produce a usable UI quickly that will not break in bizarre ways.
Same goes for PyQT, a few hours starting from scratch(ie not knowing anything about PyQT) and you can make something usable.
WxPython same thing, classes in a control such as wx.dataview look normal enough.
Bootstrap does away with a lot of them.
Having said that, statically linked wxWidgets .exe files are usually smaller than Qt .exe files. Moreover, dynamically linking to Qt does have technical advantages for certain types of applications (mostly plugin architectures).
Shameless plug: You can create all variants (Qt or wxWidget, each statically or dynamically linked) very conveniently on your Linux build server via cross-compiling, which has become really easy thanks to the MXE project that I started in 2007.
http://mxe.cc
Heavily object-oriented code and custom scripting languages that are really hard to understand and use, and when there were problems (memory leaks, reference counting) I was stuck 15 (Qt) calls deep somewhere in the huge codebase.
Thanks, but I'm now doing it myself and learning the right abstractions (and sane software architecture in general), instead of spending my time learning the incantations to make this elephant move the way I need him to.
For Python I like Qt quite a bit because the loose signal/slot approach meshes nicely with a dynamic language.
Full changelog: https://github.com/wxWidgets/Phoenix/blob/master/CHANGES.rst
Migration guide: https://docs.wxpython.org/MigrationGuide.html
I glanced at the information and, if I understand it correctly, 4.0.0 is the first release of a ground up rewrite.
What's not immediately clear (and perhaps because I did not read the material clearly enough) is if any significant features were added. I wonder because I find it hard to rewrite something without taking advantage of the opportunity to add features. Or perhaps the desire to add features that would be difficult with the 3.x.x code drove the upgrade.
I find wxPython highly productive and enjoyable to work with and the wx C++ documentation has always been outstanding. Now the Python docs are also really good! https://docs.wxpython.org/
I know that Qt gets most of the publicity, but personally I prefer wx (having written huge applications in wx and only a small one in Qt, but still). Being able to .Bind() anything without sub-classing and the fact that the class constructors normally takes sensible parameters so that no further method calls are needed to set up a widget makes it very fast and compact to generate dynamic UIs with readable code.
The work Robin Dunn has done with wxPython is simply massive and he should be known as one of the great open source legends, especially in the Python community! Congratulations on a fantastic release!
Wonder if they think 4.0 is compatible with 3.0?
Either way it's still available on sourceforge, see the bottom of: https://wxpython.org/pages/downloads/
Does somebody knows which API interface specification is most suitable for that kind of communication on a single PC: Swift <-> Python ? For web it easy (e.g. REST) but there has to be other options on a fully controllable code base on your PC (seems my desktop programming days are long gone.. otherwise I would know myself)
Compare these pages...
* Overview, https://www.wxpython.org/pages/overview/
* API, https://docs.wxpython.org/
* Demo, https://wiki.wxpython.org/WxSmallApp
...with these pages for Bootstrap:
* Overview, http://getbootstrap.com/
* API docs, http://getbootstrap.com/docs/4.0/getting-started/introductio...
* Demo, http://getbootstrap.com/docs/4.0/examples/
For me, this difference made web UI frameworks much more approachable. Visual widget catalogs simplify the task of finding widgets or code samples. Widget screen shots help determine if code is performing as expected.
They're also not HiDPI/Retina, and the whole website design seems to be stuck in the mid-2000s, too. Somehow mobile and web developers got aboard all the new design and interaction trends, but Desktop GUI frameworks seem to be all stuck 10 years behind.
If I had to guess, I'd say it's probably because of a lack of capital investment in desktop software.
And yet a lot of people don't understand why everyone is using Electron for desktop apps these days.
Either way, at least in my experience, I had to look up the C++ documentation because the Python binding documentation was never complete.
Because the new design trends are all about how to adapt to the limitations (and possibilities) of mobile and web. For desktop applications these mobile-first designs don't work very well (see Windows 8) and we already had long-established design patterns that do.
I have been using wxpython on and off for last a few years, the nice thing is it gives a natural looks on each supported OS, so your application won't standout as odd/fancy/weird/off, as with some other cross platform GUI framework do;
Are there any Python projects out there that allow you to ship a "binary" (even if it's just a self contained python with the relevant libraries like WxPython brought in) for people to use?
They are shipping Python 3.5.2 + required PyQT5 parts + other python libraries. Only Python files visible for users are in plugins folder (rest are bundled[as pyc-s] in single zip file, python interpreter is "merged" with entry *.py file as an executable).
You can easily download Cura from Ultimaker site and "inspect" result yourself ;)
[1] https://docs.wxpython.org/events_overview.html