jmoiron.net

When I first started using python+gtk+glade/libglade, I didn't think that any other programmers had it better than me. I was still in a platform dependent stupor, a sublime state of anti-idiocy insanity where my own idiocy was incalculable and yet undetectable, but then again I had never had any experience developing Gui's even though simple tools were most likely available. My PyGTK Tutorials, available still in the docs section, are a testament to how much I enjoyed the system, as well as how much I began to understand it.

With PyGTK/glade/libglade, I was introduced to:

• My first experience with Python
• My first experience with a good GUI designer
• My first experience with a graphical toolkit

It might sound silly, but I never viewed anything before in those contexts, so I never really participated in the glorious insanity of it all. Getting PyGTK and libglade set up required the compilation of 3 packages, which I was forced to do several times, although mostly because I forgot the --prefix=/usr configure option. Still, I got it set up with relatively few problems, and about ¾ of the sample code worked, with the other ¼ listed as broken on the PyGTK site.

I joined some mailing lists, read some O'Reilly books on Python programming, read all of the FAQ's about GTK and how it worked, and basically learned the whole system as if I was a C programmer merely writing executable pseudo code. The best part is that I basically was. I got a text editor up and off the ground (and working) 4 days from wanting to start playing with it, which for someone with really only 1 core language is quite good. We'll compare it to my time with QT shortly.

The PyGTK/glade days introduced me to many tools, ideas, and people. It made me grow infinitely as a programmer, able to express myself in the then almost forgotten object oriented approach, which would be an invaluable addition to my programming knowledge. I went onto serverside python programming, dealing with the cgi module and postgreSQL module and redoing this site in python. The dormancy of these tasks, which I have only followed up on in a cursory way recently was radically shaken this week.

Trying out SWareT, I decided to write a front end in, of course, Python. Python would give me the flexibility and development speed to surpass the only other established project as well as give me the opportunity to develop for both toolkits quickly. In less than 4 hours this morning, I got all of the packages I needed for Qt(only) development in Python with similar constructs to my PyGTK/glade environment. There are a few key differences, however:

• The Qt UI generation seems simultaneously far more powerful and far less optimal than glade's
• The step for taking designer .ui files to usable code (in one way or another) is done at compile time, much like C's implementation of libglade. This increases speed and allows for widget tweaking to be pre-initial bytecode interpretation step: the speed gains for this have been thusfar indiscernible
• The PyGTK set of tools was 3 packages; the Qt set of tools was 5, one of which is currently incompatible with the rest of the "distribution".

So, my overall difficulty with Qt so far? Definitely the widget placement is not as intuitive as the GTK+ "container" module, and not as elegant (although I'm not sure if it allows me to do things that GTK+ won't), but the major difficulty in programming in python using Qt is, oddly enough, C++. G++ is entirely inadequate in terms of its speed facilities; otherwise I'm sure its an entirely viable and in fact probably excellent compiler. However, waiting 45 minutes for bindings to compile is not how these things are supposed to work. And with 5 packages to compile, almost all of them having C++ source, this extends the process mightily.

My problem with Qt designer can be best described with an example from the excellent yet esoteric manual.

> * Click the decimalsSpinBox and press Shift+Click on the spacer next to it. Click the Lay Out Horizontally (Ctrl+H) toolbar button. > * Click the form (to deselect anything that's selected), then click the form to the left of the Decimals text label and then drag the rubber band so that it touches every label and widget, including the decimals spacer, but avoiding the other spacers and the push buttons. Release the mouse and notice that the desired widgets are selected. Click the Lay Out in a Grid (Ctrl+G) toolbar button. > * Click the Clear push button in the Object Explorer window (Objects tab) and then Shift+Click the Calculate push button, the Quit push button and the Spacer between the push buttons. Click the Lay Out Horizontally toolbar button. > * Click the form to deselect all the widgets and layouts and then click the Lay Out Vertically (Ctrl+L) toolbar button. > * Finally, click the form and then click the Adjust Size (Ctrl+J) toolbar button.

What the fuck? The process describes how to get UI's designed with Qt Designer to not act stupidly; ie: to not have static sizes and positions, but grow with the window. The design of Qt should probably take care of this by default and at the very least Designer should get it out of my hair.

My other large gripe is that the whole development environment does not seem "unix-like". It was easy for me to use only Glade to create python programs, since Glade itself was independent of the source code implementation. Qt Designer works in a like way, but rather than create python libraries that come with PyQt to handle the XML output of Qt Designer, most tutorials that I have read thus far rely on an IDE named Eric to convert the UI to a python module. The end result is cleaner than the current GTK+ solution, but at what cost?

At the cost of adding 2 extra dependencies, and, if you are like me and did not anticipate this, another recompiling (45+ min on an Athlon 1.4 GhZ w/ 1 gig of ram). Not only this, but these dependencies seem like they are for things that would not be needed by most people using Qt Designer; the requirement? Scintilla and the QScintilla bindings. Why the Eric developers would go for a text widget that handles facilities that native C++/Qt widgets already handle seems puzzling, although it becomes apparent that the whole tool set wants to remain as far from KDE as possible. Hence, no Kate text widget. This all means, of course, that I need GTK+ anyway, since Scintilla is written for GTK+.

The IDE itself is largely useless to me, as non-antialiased text is largely an exercise in pain on my LCD monitor. So there are 3 things I have on my computer related to this IDE (including the IDE) that I need to do the things I want to. Heres to hoping that something is done about this by the PyQt devel group!

One of the nice things was that all of the sample code worked, the documentation for the actual programs that I am using is rich, which cause less lookups to the mailing list or to google. The system itself seems almost as easy and friendly to develop in as GTK+: I just wish that PyQt was a more standard component of Qt/KDE (although it is my wishes that PyGTK also gets recognized a bit more than it is now).