Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Best GUI package for Perl ?

by rbutcher (Beadle)
on Jul 25, 2004 at 06:26 UTC ( #377233=perlquestion: print w/replies, xml ) Need Help??

rbutcher has asked for the wisdom of the Perl Monks concerning the following question:

Venerable ones, I'm developing some GUI frontends to submit and monitor some batch jobs on Linux/KDE and natch want to use Perl.. my first venture into GUIs. I've looked at Tk and Qt.. any others ? Any opinions out there on comparative merits, or any published articles ? I need commercial-quality appearance, and have found it difficult to control colors in things like file-selection widgets in Tk (some options seem lacking). thanks. Rod

Replies are listed 'Best First'.
Re: Best GUI package for Perl ?
by runrig (Abbot) on Jul 25, 2004 at 07:09 UTC
    Look through the (GUI) Windows Programming FAQ. There's Tk, Wx, Gtk2, Qt, Prima, Win32::GUI (have I missed any?).

    Update: to expound a bit on my limited knowledge of Tk and Wx, IMHO Tk seems more appropriate to throw together a utility with a single or small number of screens (because of the tendency to rely on globals mentioned further down this thread). If I were building a GUI app (something Jouke would know about), I'd probably go with Wx. Gtk2 and Qt are other options that other people like, but I don't know enough about them to have any opinion. Win32::GUI is, of course, only for Win32 systems, and I don't have any opinion on that either. My plan is to eventually try them all. I'll let you know when I do :)

Re: Best GUI package for Perl ?
by zentara (Archbishop) on Jul 25, 2004 at 11:56 UTC
    If it's your first GUI, I would stick with Tk. The reason is the support available. The other GUI's may have some technical superiorities, but when you hit a roadblock, you are often on your own. Whereas the more numerous Tk users are always willing to help with problems.

    As far as appearance goes, you can put as much into it as you want. There is nothing stopping you from making your own custom file dialogs, based on a canvas or dirtree in a toplevel widget. You can make the dialog look like anything you want.

    As an example, here is the beginning of a custom file dialog, which looks "pro". You just need to "flesh it out".

    #!/usr/bin/perl use strict; use Tk; require Tk::DirTree; require Tk::Adjuster; require Tk::TList; # The initial directory my $initial_dir = '/'; # The main window... my $main = new MainWindow( -title => 'Explorer)' ); # A frame for the tree, adjuster and tlist my $tree_adj_tablist = $main->Frame(); $tree_adj_tablist->pack( -expand => 'yes', -fill => 'both', -side => 'top' ); # A scrolled directory tree my $tree = $tree_adj_tablist->Scrolled( 'DirTree', -width => 35, -height => 25, -scrollbars => 'osoe', -background => 'White', -selectmode => 'single', -selectbackground => 'DarkBlue', -selectforeground => 'White', -showhidden => 1, -directory => $initial_dir ); $tree->pack( -expand => 'yes', -fill => 'both', -padx => 2, -pady => 2, -side => 'left' ); # An adjuster my $adjuster = $tree_adj_tablist->Adjuster( -widget => $tree, -side => 'left' ); $adjuster->pack( -side => 'left', -fill => 'y' ); # A scrolled tab_list widget my $tab_list = $tree_adj_tablist->Scrolled( 'TList', -background => 'White', -orient => 'vertical', -selectmode => 'extended', -scrollbars => 'os' ); $tab_list->pack( -expand => 'yes', -fill => 'both', -padx => 2, -pady => 2, -side => 'right' ); # A Quit button (will be suppressed???...) my $quit = $main->Button( -text => 'Quit', -underline => 0, -width => 6, -command => sub { exit } ); $quit->pack( -side => 'right', -padx => 10, -pady => 10 ); # Configuring tree and tab_list widgets... $tree->configure( -browsecmd => sub { list_dir( $tab_list, @_ ); } ); # We list the content of the initial dir inside the tab_list list_dir( $tab_list, $initial_dir ); MainLoop(); #--------------------------------------------------------------------- +------- # Displays Dirs and files in TList widget sub list_dir { my ( $tab_list, $path ) = @_; # Erase the TList content $tab_list->delete( 0, 'end' ); opendir MY_DIR, $path or return; foreach my $file ( sort readdir(MY_DIR) ) { # Do not display '.' and '..' next if ( $file eq '.' or $file eq '..' ); # Insert the files in the TList $tab_list->insert( 'end', -text => $file ); } closedir MY_DIR; }

    I'm not really a human, but I play one on earth. flash japh

      With Tk there is lot of cruft accumulated, and there are pretty complicated solutions to simple problems, that, although ugly, DO WORK.

      If you don't want to bury yourself in those details, choose something better designed... or rather 'designed in modern times'.

      I've hit similiar walls trying to work with ncurses - it's very old, there are loads of working applications outthere, but you've got no working higher-level toolkits like Cdk or similiar to 'Turbo Vision', and people just learned how to adjust...

      OTOH having worked with Tk, moving to perl's Gtk2 was just pure pleasure, without experiences with Tk, fltk etc.. I would just take Gtk for granted and would bitch about it alot... ( especially since there are some snags in Gtk2, the advantage is that they're being worked-on, and there's hope of seeing fixes soon, with things like Tk - no fixes for you.)

      If it's your first GUI, I would stick with Tk. The reason is the support available. The other GUI's may have some technical superiorities, but when you hit a roadblock, you are often on your own. Whereas the more numerous Tk users are always willing to help with problems.

      Yeah, and let's all use Windows, a QWERTY keyboard and code in PHP.


      Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

        Why poo-poo a good suggestion like this? There's no reason to make things hard for oneself when learning, by using a little-known, not-so-widely-spread system. Note the 'when learning', once GUIs are understood in general, then one can apply the knowledge to others to try them out.

        There's nothing quite as frustrating as sitting in front of the computer, with inadequate documentation, and no other help in reach, when one is learning something new. (Peopleo may boo me, but its the reason I would reccommend Windows to anyone completely new to computers who wants to get started, its just a lot easier to find people who know at least something about it next door, at the pub, at school, whereever. Unless one is in an environment (like school/uni) where there are large amounts of people knowledgable about linux/mac/whatever else)..

        waffle.. waffle..


        If I'd have thought some before posting, I might not have bothered posting this.. Maybe if you had too..

        Well the monk asked for advice about the best GUI to use for his situation. If he was a "top-notch programmer" like you, he wouldn't be asking this question here. To compare using Tk to using Windows,Qwerty, and PhP; shows a bit of ignorance on your part(or is it your ego?).

        I suppose we should tell the OP to dump Perl too, since Python is "more advanced" in it's design? Perl still stands strong, because it makes things easy to do, as does Tk.

        ....Tk is solid, active, and moving forward day by day, just like Perl.

        How many times have you seen this same question asked before, only to see a post a few weeks later, saying the poster decided to go with Tk because it was easier and faster to do?

        I'm not really a human, but I play one on earth. flash japh

        Actually I think you are totally out with regard to keyboards. Especially if you are a professional programmer and don't have specific medical reasons for avoiding Qwerty keyboards. The advantage of being able to use any machine at close to your normal typing speed is pretty clear. Sure Qwerty sucks, sure its designed to slow your typing down, but its the most common keyboard layout by far and if you cant type at touch-typing speeds on one then you are at a competitive disadvantage if you move from job to job. Many establishments have rules prohibiting the use of non-standard equipement so bringing your own wont really help.

        I speak with a bit of expeience with this as I normally type on a UK layout keyboard, but I live in Germany where the layout is different, I used to even have a US keboard at home and UK at work but that just made things worse. I mistyped so often it wasnt funny. So now ive standardized on the UK layout. This puts me at a disadvantage when I use a colleagues machine or help someone out on their box. I can just imagine how much worse it would be if I didnt use a Qwerty variant.

        Incidentally, I find that from an ergonomic POV German keyboards really suck for programming, and suck for programming perl even worse. The fact that all braces/brackets have to be typed with the right hand while the right thumb is pressing the alt-gr key is a total nightmare. It wouldnt suprise me if German coders (and other non-english coders with similar layouts) have above average (compared to english/american coders) levels of stuff like carpel tunnel and RSI.


          First they ignore you, then they laugh at you, then they fight you, then you win.
          -- Gandhi

Re: Best GUI package for Perl ?
by gaal (Parson) on Jul 25, 2004 at 06:37 UTC
    Everyone has their favorite, I guess. Mine is GTK2 (Perl bindings).

    It's a well-designed, well-documented, and well-maintained toolkit.

Gtk2 + GladeXML
by Eyck (Priest) on Jul 26, 2004 at 06:35 UTC

    I find GladeXML-based programming very refreshing, I used to churn code based on Tk, and this code was a real spaghetti, gui stuff mixed with actions mixed with logic ... horrible.

    With Gtk2 and GladeXML you write your code, and seperately you draw your application, glade spews xml describing how your app should look, and you write what this app should do.

    And this work equally well under UNIX oses and under windoze ( although on windoze you have to go through painfull process of installing gtk and gladexml - in my case this requires installing compilers etc... ). And the code can look like this:

    use Gtk2; use Gtk2::GladeXML; #This loads description of your GUI, from file named open (GLADE, "<", $sharedir.$execname.'.glade'); my $gladebuf; while (<GLADE>) { $gladebuf .= $_; } close (GLADE); $gladexml = Gtk2::GladeXML->new_from_buffer($gladebuf); # # This way you get the object you want to work on: my $window=$gladexml->get_widget('window'); # There's nothing stopping you from doing this on-the-fly: $gladexml->get_widget('userName')->set_text($userName); ############ sub on_something_something { my $w=$gladexml->get_widget('SomeWidget'); $w->show_all(); $w->run(); $w->hide(); } # Gtk2->main; exit 0;

    And now, you can easily modify your apps look without touching the code, for example, you can take some window and turn it into a tab, or reorganize forms etc etc... This sounds like a great thing for teams with separate UI-designer, but this kind of development feels great even for single person, it's just so much easier not having to think about both functionality and looks at the same time (even if you switch from one to another every second, it's easier to work if you've got two virtual desktops dedicated - one for code, another for GUI).

      "I used to churn code based on Tk, and this code was a real spaghetti, gui stuff mixed with actions mixed with logic ... horrible"... !! Thanks Eyck and all the other guys for your feedback. I just finished my first effort with Perl/Tk and I ended up with 600 lines that look just as you describe above, even though I think I understand the event handler concept... I just couldn't separate stuff like freezing/unfreezing buttons, from stuff to fire up and monitor the background process (via 'After' callback), from stuff to load and validate parameter files, from error handling (very important that absolutely any problem must produce coherent output), from stuff to cleanup zombies on process cancellation... horrible. I got Perl/Tk to do everything I wanted, but it is unmaintainable code. So big plus and big minus. Anything out there to force some function separation into Perl/Tk ? Meantime I'm looking at Perl/Qt (nice looking design tools, but what a name - Puic !?). Then I'll look at Glade/Gtk, sounds interesting. thanks & regards Rod
        You're asking for function separation in Perl/Tk? Well, just do it! It's the same as in normal non-GUI programming. You can use subroutines, you can use modules. Granted, there are some nice features in Tk which allows for writing quick scripts (e.g. -variable, anon subroutines in command bindings), but nobody forces you to use these features.

        This is just like people complaining about Perl to lead to unmaintainable code. You can write unmaintainable code in both Perl and Perl/Tk, but you can also write nice code if you use the language and module wisely.

Re: Best GUI package for Perl ?
by gmpassos (Priest) on Jul 25, 2004 at 22:41 UTC
Re: Best GUI package for Perl ?
by wolv (Monk) on Jul 25, 2004 at 23:29 UTC

    Even though a part of the decision is your preference, I think wxWidgets (formerly wxWindows) is a very good choice. The Perl bindings are on CPAN (look for Wx), as well as on Sourceforge. wxWidgets is a cross-platform GUI toolkit that can use different engines - Motif, Gtk(2), and the native ones on Win32 and MacOS.

    However, not all the classes provided by wxWidgets are implemented (or wrapped, rather) by wxPerl yet. I'm sure help on the development is welcome.

    If being cross-platform is not an issue, I would consider the Gtk2 bindings on *nix, probably. It is a relatively nice API and most importantly, it looks good. :)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://377233]
Approved by davido
Front-paged by broquaint
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2021-10-21 22:10 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (85 votes). Check out past polls.