I know what you mean. It gets even more gruesome when you want to dynamically recompose your GUI (changing labels, changing the input widgets available according to the setting of a dropdown etc) as you have multiple objects to pass to subroutines. E.g. if you want to change the labels on 5 text fields, and remove 2 other textfields and their labels, based on a drop down setting, you have 9 separate widgets to update, and unless you start doing fiddly things like getting a list of children from the parent, you have to pass them all in).

I tend to put the Tk object itself, and widgets that I know I'm going to have to twiddle, in a hash called something like %tkObjects, and pass that to any piece of code that requires GUI update functionality. If you're coding from an OO perspective, you can make that hash an attribute of an object, and consider that the object 'has a gui'. You then end up with code that looks like:

sub update_button
{
  my $self = shift;
  my $buttonobj = $self->{tkobjects}->{submitbutton};
  $buttonobj->#do something with the button
}
[download]

From a non OO point of view, you might consider that your subroutines are doing two things: doing the necessary processing, and updating the GUI.

That technique is on dodgy ground for the principle of narrowest scope for variables & objects, but conforms with laziness and impatience nicely :)

Alternatively (and I hate myself for saying this), you could make certain very carefully chosen objects global.

I'm certain there are better ways, but those are the two I've used.

Update: You could also put all the GUI construction and update in one place, and update the UI according to the return values of subroutine calls. That way is perhaps neater from a design point of view, but can rapidly end up with a really huge main gui function that's difficult to maintain. So thats a third, equally vile, approach that I've tried.