Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: GUI toolkit choice

by g0n (Priest)
on Oct 15, 2006 at 11:55 UTC ( [id://578370]=note: print w/replies, xml ) Need Help??

in reply to GUI toolkit choice

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."
John Brunner, "The Shockwave Rider".

Replies are listed 'Best First'.
Re^2: GUI toolkit choice
by ambrus (Abbot) on Oct 15, 2006 at 14:50 UTC

    I agree with you. I had to write Wx programs in C++ for a university course. The containers are quite logical, more so than in Tk. The documentation is good. On the other hand, I had problems installing it on my home machine, so IIRC I just compiled and ran all the programs on the university machines. (This was three years ago, it probably improved since.)

Re^2: GUI toolkit choice
by sir_lichtkind (Friar) on Oct 16, 2006 at 08:02 UTC
    IMO Wx docs are good.they are complete easy to understand und almost desciptive. And you got topic overviews, and some views more. and all differences between c++ and wxperl are marked right in place so you never be wrong. what it really lacks is that its not so easy browsable. chm version is better that html but a nice API browser like some ruby folks have vor wx and like we once planned it vor wxperl would definifly be a big gain.

    my 3 eurocents

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://578370]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (6)
As of 2024-04-21 21:50 GMT
Find Nodes?
    Voting Booth?

    No recent polls found