If the server and client are talking through TCP/IP and you are using sockets to implement that then you should be able to use select to detect when an event happens. You can use a time out with select.

I believe a quick and dirty implementation could involve forking the client so that the parent handles communications (the select loop), while a child handles the user interface. The child and parent can communicate through TCP (or UNIX sockets) and the parent will be able to deal with that in the same select loop.

client program connects to the server (fd a)
client program opens the windows etc.
client program forks.

   parent:
     wait for the child to connect.
     go into select loop (blocking)
        was it the server :---> paint the incoming message
        was it the child  :---> send message to server
        was it the child and user wants to quit:-> shutdown
            (remember to kill child).     

   child:
     connect to parent
     loop: if user types something send to parent
[download]

Hmmmm... Inelligant I believe, but then I'm not being graded on this (am I?). Multi threading would be much better. But I don't know what that would do to Perl/Tk

-- termix

#!/usr/bin/perl -w
use strict;
use Tk;

#set up our window and some interactive feature
my $mw = Tk::MainWindow->new();
my $button = $mw->Button( -text => 'Pop', -command => sub {print "pop!
+\n";} )->pack();

#set up our periodic task.
#this executes faithfully every x milliseconds
$mw->repeat(5000, \&waiting );

MainLoop;

sub waiting {
    print "waiting...\n";
}
[download]

Instead of client/server, why not try a master/slave relationship where the master will push the content out to each connected slave?

Is that too much of a simplification?

Back to the thinking board.

If each chat line was indexed with a sequence, the slave would then request each bit of additional content greater than the last bit recieved, less some time out period, so they dont get 5 weeks worth of chat downloaded to them.