I've been known to use this same approach myself for self-contained Perl/Tk apps of similar size (even larger) -- a global hash that holds all the widgets makes it easy to access any given widget from within any given callback subroutine, and this is handy when the callback for some widget or bound event has to reconfigure one or more other widgets, which might be anywhere else in the GUI.

Given sensible hash key strings, this seems easy enough to maintain (and to "add features" or change the app's behavior later on, when needed). So, I know globals are "naughty" for various good reasons, but they can be a viable option -- they do have their place, I think.

If there is a better way (without the global hash) in such a case, I'd be grateful to see it. (I come here to learn stuff like that.)

There are cases where globals are fine, especially in smaller apps.

A common way to do a "global variable" is to use a Singleon. I would recommend using Class::Singleton vs. rolling your own, but the basic idea is:

package Dragonchild::Singleton;

my $singleton;

sub new
{
    my $class = shift;

    $singleton ||= bless {}, $class;

    return $singleton;
}
[download]

No matter how many times Dragonchild::Singleton->new is called, the exact same variable is returned. It's partially a style issue, but I prefer singletons over our'ed variables. Other monks will tell you the opposite. TMTOWDI

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.