Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

GUI toolkit choice

by jbert (Priest)
on Oct 15, 2006 at 10:38 UTC ( [id://578368]=perlmeditation: print w/replies, xml ) Need Help??

Hi,
A quick search only showed a Tk/Gtk discussion from 2001, so I hope I didn't miss something and this is a FAQ. Also, I'm hoping that we can discuss things without having a religious war about which is 'best'.

That said, I'm interested in finding out more about the various options for GUI coding, particularly - but not exclusively - from perl.

The main options I know of are:

  • Gtk+ - originally written for the GIMP, used by the GNOME people and some other apps
  • QT - written by Trolltech, used by the KDE people and some other apps
  • Tk - from Tcl and ported to perl early on
  • WxWindows - seems good but I know little of it (the DrScheme IDE is written in it and seems decent)
All of these are cross-platform (at least Linux and Windows and I would guess Mac and 'general unix/X windows as well').

I've used Gtk+ from perl and C++ on Linux with good results and the same scripts runs on Windows (once Gtk is installed), which is nice.

If anyone has experience of more than one of these toolkits and can provide some thoughts on what they see as the most significant strengths and weaknesses of them I'd be grateful.

And I'd hesitate from using this thread to ask the popularity of the different toolkits, but perhaps that would make a good poll?

Replies are listed 'Best First'.
Re: GUI toolkit choice
by g0n (Priest) on Oct 15, 2006 at 11:55 UTC
    I've used Tk fairly extensively over the last few years, and am now starting to get to grips with Wx.

    Tk

    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

    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".

      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.)

      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
Re: GUI toolkit choice
by zentara (Archbishop) on Oct 15, 2006 at 13:04 UTC
    Oh well, I have to throw my 2 cents in. :-) In my case, it's a choice between Perl/Tk and Perl/Gtk2. I never got into Wx because it's a bear to install and it's too OO for my tastes. Perl/Qt is old has isn't being actively updated.

    Tk is easy to learn and fun. Gtk2 is more difficult, because it gives you more control over everything, from the signals to the underlying Gdk windows.... but that complexity can cause alot of trouble until you figure it out. BUT once you do figure it out, man can you do cool things in Gtk2, like custom-shaped windows.

    Gtk2 is actively being developed with the c-libs having bug-fix updates released monthly, and the Perl modules following shortly. That inspires me, and makes me see a bright future there. On the other hand, Tk is like an old-but-solid-toy..... it's still there, easy to play with, but it dosn't quite match up with the glitz and new features of the Gtk2 toy. For example, Gtk2 labels allow you to use pango-markup strings(mixed color and font size), where Tk only allows simple strings. On the flip side, you can't bind to a Gtk2 label, without an event box underneath it. Tk lets you bind to the label.

    The one real advantage of Tk, IMHO is the Canvas(and it's steroid-pumped brother Zinc). They both exceed the Gtk2 Gnome2::Canvas (which has lost development status). I think Canvases are where the action is. You can make anything on it, and it runs well. I will mention that replacements for Gnome2::Canvas are in the works.... so the future may be bright there too.

    Finally, one other advantage to Perl/Gtk2, is that once you get something running, you can port it to the C version of Gtk2, for a faster compiled version (assuming you have that skill ).


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: GUI toolkit choice
by vkon (Curate) on Oct 15, 2006 at 12:06 UTC
    I use Tk (but not perl/Tk, rather Tcl::Tk module), and I have little need to search something different.
    I tried some native-Win32 programming via perl also, but got rid of this way in 199x
    Here are my experiences for your list:

    • Gtk+ is advanced but complicated to use. It could be more advanced compared to Tk in some aspects, but due to its size there are many drawbacks
      Its like programming C these days. You really must use C for some kind of projects, but I prefer Perl for 99% of tasks.
      Its size makes it difficult to move, also I am sure it ill never be in PocketPC.
    • QT - nice look, but cost too high. When I hear voices around QT "if you're good programmer you'll cover this cost quickly within your brilliant programs, otherwise QT not for you" - stupid bull*hit; if I have extra $3000 I'll buy notebook PC for my toliet room.
    • WxWidgets - I did very small research on this (hardly going further running few demos and looking through examples)
      Very impressive, high potential, but not enough for me to move from Tcl/Tk

    BR,
    Vadim

Re: GUI toolkit choice
by bart (Canon) on Oct 15, 2006 at 13:09 UTC
    You forgot a few GUI toolkits in your list. There's at least, Win32::GUI, and Prima, too. Now the former is Windows only (and the most Windows native toolkit of them all), but the latter works on many platforms.
Re: GUI toolkit choice
by mikasue (Friar) on Oct 15, 2006 at 12:07 UTC
    I have experience with Tk.

    I chose Tk because
    #1 I was learning Perl and wanted to add a GUI to a program I was writting. What better way to use what I was learning and accomplish a task.

    #2 Tk was easy to pick up. Granted the geometry managers took some study but everything else was a piece of cake. I particularly found the widgets interesting and there are soooo many more widgets available than the standard ones.

    #3 Perl is fun so by default Tk is fun!

    What I don't like about Tk is um um
    #1 well I had some issues with the placement of the Dialogbox widget

    #2 I have problems packaging my programs sometimes with pp or tkpp

    All in all if you need an easy, fun, quick GUI solution Tk is the way to go.

Re: GUI toolkit choice
by ides (Deacon) on Oct 15, 2006 at 15:10 UTC

    While I'll agree using Gtk is *harder* than using Tk, the result is a much better user interface. No offense to Tk, but when I see an app written in it I immediately think "ah how cute, a GUI app written 10 years ago" even if it wasn't. I guess it really depends on your target audience, but I don't even use Tk for personal GUI apps any longer.

    One way to get around some of Gtk's code complexity is to use the Glade IDE to build your interface and then simply "load" it with Gtk2::GladeXML. This limits your code to only writing the callbacks, which is the interesting part anyway.

    Frank Wiles <frank@revsys.com>
    www.revsys.com

Re: GUI toolkit choice
by TGI (Parson) on Oct 15, 2006 at 20:39 UTC

    No one has mentioned Tkx yet. I haven't tried it, so I can't comment.

    I've experimented briefly with Prima, Wx and Gtk. The problem I have with these toolkits is that the docs are lacking. Prima and Wx seem particularly nice. AFAIK, Wx has the advantage of being the only gui toolkit that works on Mac OS X without X windows (except for CamelBones based apps, which only run on OSX).

    I've done some big projects with pTk, and it definitely has some warts. But it wins by being well established and having lots of docs available, including a book.


    TGI says moo

      ++ for mentioning Tkx!

      It uses Tcl to connect to Tcl/Tk, which is now the way to go for Tk applications!

Re: GUI toolkit choice: how about some web browser action?
by andyford (Curate) on Oct 16, 2006 at 03:32 UTC
    I think you should check out some of the "web2.0" things like prototype and scriptaculous . For my purposes, perl CGI programming combined with some fancy javascript is increasingly making classic GUI programming obsolete.

    andyford
    or non-Perl: Andy Ford

Re: GUI toolkit choice
by wazoox (Prior) on Oct 16, 2006 at 07:01 UTC
    I suppose we should also mention Tk::Zinc. I don't use it personnally, so I won't comment though.
      its not a GUI toolkit, bro
      its advanced widget(s) of larger GUI toolkit
      :)
Re: GUI toolkit choice
by ailivac (Sexton) on Oct 22, 2006 at 04:27 UTC

    Although I haven't done much GUI work in Perl yet, I've been very pleased with WxWidgets so far. It's not as powerful as GTK+, or as pretty always (even though it uses GTK+ as a backend on unix, there are sometmes holes where real GTK+ apps look better) but it was easy to learn and WxGlade can output perl code for quick prototyping.

    The other big advantage of Wx is that it uses native toolkit widgets instead of drawing its own. That way you can ship programs to people on different platforms and it will look like most of their other applications, as opposed to things like Java Swing which look the same on all platforms but nothing like other programs on those platforms.

    Tk was popular in the past probably because it was easy to use, but now that it's so ugly and clunky compared to modern toolkits, the extra effort to learn Wx or GTK+ is probably more worth it now.

Re: GUI toolkit choice
by radiantmatrix (Parson) on Oct 26, 2006 at 16:10 UTC

    I have used Wx, Tk, and Gtk+. I favor Wx, despite it's problems (dependency considerations can be annoying when pacakging), largely because it allows me to write a single app that looks native on Win32, Linux, and OS-X.

    Tk apps always look like Tk (which is sometimes an advantage...). Gtk+ apps rely on appropriate Gtk themes being available for OS-appropriate look-and-feel.

    So, my favorite is definitely Wx. However, my second choice is Tk for the utter consistency it can provide, which is advantageous when writing the kind of apps that will be used by the same user on many platforms.

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://578368]
Approved by Corion
Front-paged by Courage
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2024-03-29 14:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found