|No such thing as a small change|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
I've used Tk fairly extensively over the last few years, and am now starting to get to grips with Wx.
Tk has the advantage that it is very widely deployed (it's shipped with Activestate perl for example) and builds fairly easily if it didn't come with your perl install. If like me you like to prototype with a GUI builder, there's ZooZ, which is easy to use, and although not particularly fully featured, has some nice features, like the ability to output a megawidget. Since reading qumsiehs answers to my post on the subject (Writing and maintaining Tk GUIs with ZooZ) I've used it fairly extensively to create a starting point for my code, generating a base window and megawidgets to populate the base window with.
On the other hand, Tk has the disadvantage that it's a little crufty to manage your widgets, as discussed here: OO circularity. Lately I've taken to writing Tk GUIs from a largely MVC perspective, creating worker classes and then writing a script that is basically just a view. This usually starts out autogenerated from ZooZ, so all the widgets are in a global hash called %ZWIDGETS. As long as your view script isn't too big, thats reasonably OK to manage. If coding the thing from scratch, it would be cleaner to pass the widget hash around the functions in the view instead of globalising it. The syntax for creating megawidgets is a little convoluted and difficult to follow, although I tend to let ZooZ create the megawidget, then manually insert the functionality that I need. For example, I have an application that monitors a couple of dozen components, across 3 servers. The megawidget receives a list of components on the server, and iterates through the list creating Tk::Statusbox widgets for them within the frame of the megawidget.
The Tk API has changed over time, which can be a bit of a nuisance. For example, 'cols' as a parameter to 'grid' used to be permitted, now it isn't. The behaviour of widgets when disabling has changed too, one used to have to grey them out manually. This has caused me a good deal of grief between AS Perl 5.6 and AS Perl 5.8, requiring quite a lot of code changes just to get some of the older code to compile.
Wx on the other hand can be an absolute mare to install. Really, really horrible dependency problems. But once you've got it installed, it's easier IMO to keep your code neat and well encapsulated. Because everything is based around extending the existing classes, and any given widget can access its parent/grandparent, as well as a list of child widgets, there's less of a difficulty with accessing widgets at the appropriate time without passing damn great lists of widgets or a single hash of widgets all over the place.
The construction of megawidgets in Wx is more logical, it is after all just a case of creating a class that contains the widgets you want. That follows on from the basic Wx syntax more logically than Tk's rather convoluted approach.
The documentation for Wx, at least from a perl point of view, is not great. On the other hand, once you get the hang of looking at the C++ Wx documentation and infering what you want from that, it's easier than you might think (and I'm not a C++ programmer).
If you want a GUI builder, wxGlade can write perl code. I haven't had chance to do much with this, since we primarily use Tk at work.
In the future, I think I'm likely to move more towards using Wx for my own projects. The OO basis of the syntax just looks cleaner and better encapsulated to me (although I'm far from an expert Tk programmer - I may be missing something obvious). The problem of Wx being easily available on a given platform is potentially a bit of a sticking point, but hopefully that will change over time.
For work code, at least for the time being, it's safer to assume that Tk is going to be available.
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
In reply to Re: GUI toolkit choice