Relearning python, day 5: UI Hell
Last week, I started writing the client and UI portions of my data aggregation service. I spoke about client/service protocol frustrations in my last post, but the most frustrating part so far has been figuring out the UI. There are three parts of this:
1. Oh my god, so many frameworks!
Bindings for Tkinter, Wx, Qt, Gtk+, oh my! I’m used to two choices- WinForms if I want old, shitty, and familiar, or WPF if I want new, powerful, and intimidating. After research, my understand is that Tk isn’t much used other than to leverage the fact that it is installed by default; Gtk+, is much less used; Qt is used in Autodesk Maya but I cannot determine whether it or Wx is a better fit for me as they both seem well regarded.
2. No intellisense really sucks!
I’ve said before that I’m fine with no intellisense in python. And I was. Until I started UI work. The problem here is that UI frameworks are extremely large, stateful, and have tons of options. Intellisense helps me see all those options at a glance and greatly contribute towards understanding the framework. Even worse is the fact that so many UI signatures are *args and *kwargs, so even the limited intellisense available isn’t very useful- I need to use the API docs just to see what’s available. That realy sucks.
3. And I don’t want to use the fucking designer!
I have been a vocal critic of Visual Studio’s WinForms designer. Basically, it creates incredibly bloated code and encourages very poor encapsulation, organization, and practices. It can be extremely powerful, but for people who don’t understand GUI programming in the first place, it just results if godawful code that practically gives me an aneurysm thinking about it and makes me write run on sentences. With python, I was hoping I wouldn’t have to use a fucking designer, because I honestly barely needed it in WinForms. Except combined with the lack of intellisense, it makes designing and laying out a UI most difficult. So you’re basically forced to use a visual designer to work, which feels like I’m shitting into my mouth, unless you have the fucking API memorized, just because searching the docs for everything which feels like getting fucked in the ass.
Is this what is ultimately holding python back from greater visibility outside of the script kiddies and knowing experts? That it takes a glutton for punishment, or a genius with a lot of free time, to build a UI effectively. I wonder, if building UIs in python wasn’t so shitty, would those arrogant static typing pussies think more of it?
Unfortunately, installing pyjamas wasn’t seamless, especially for a Windows programmer. And developing in it is a little difficult, because the iteration loop isn’t quite as far as normal GUI programming. And the nature of the python-compiled-to-JS concept means only certain python modules are supported; which I see as a good thing in many ways, because it forces you to split all business logic out of the client. Good but takes a little while to get used to. It is pretty well documented, because it includes pretty excellent examples- much better and coherent than any other UI framework, though that’s probably because they are one of the only sources of documentation. That said, the devs are obviously top-notch, and committed to using pyjamas to run the site (even though they moved the mailing list onto a pyjamas-run frontend that I find really lacking right now). And it is frustrating not having all the python libraries available- you can really only use what’s written in pure python (hopefully), or modules the pyjamas team provides (which seem to be good enough in most cases).
So, look at pyjamas if you haven’t, and consider it if you’re writing any UIs. And if you are still writing rich client apps (very common in games industry) and are afraid to move into client/server land, I don’t blame you- but you’re going to have to learn it sooner or later.
I haven’t looked at pyjamas, but after reading this I’m going to take a look. I’m really enjoying these articles. I laughed out loud a couple of times reading this one. I’m looking forward to the final python opinion piece.
go qt over wx. I used wx on a fairly major app. It was ugly. qt seems way more mature. having said all that wx was the first proper UI toolkit I had ever used, so perhaps I was just missing the point.
but I’ve also used qt a bunch. it seemed to make WAY more sense right off the bat.
Your frustration was palpable and understandably so.
Is there a particular reason why you’re sticking solely with python for the UI? Are the benefits of using multiple frameworks outweighed by the overhead and integration issues they present?
We’ll I’m using python because that’s what I’m looking to learn. Since this is a server/client system, I could in theory use any language/framework for the UI that has json libraries available (as long as I avoid any python-specific stuff). It just probably won’t be worth it here since the scope is so limited.
[…] didn’t require a designer. I’ve ranted previously about what I think visual UI designer tools are doing to our children. I never once […]
[…] wrote last time about all the difficulty I had with deciding on a UI framework. Well, it turns out that was […]