The first thing I would advise is simplicity of the GUI. There can be a tendency to over complicate things. But, I have found that sometimes it is harder to design a simple GUI than a complex one because a lot of thought has to go into "what are the users going to do?" and "what info do they expect?".
One thing to consider is your "target user". From the info I've gleaned so far, you are describing an interface to a test tool which would be used by a test department or some field tech. If that is true, then some options are available to you which are better for them (more info) and you (less coding). More coding and thought is required for "just any random user".
It appears that you have some small number of main options, like #1,#2,#3. I would be thinking about making those "buttons" and the options for each button to the right hand side of each button within a "control panel". The user fills in the options like maybe "House or Apartment?", etc. Then hits the "go button", e.g. option #1. Then you reply with a typical "Ok,Cancel" screen that details what actions will be done if the user hits "ok". Hitting "Cancel" will dismiss this sort of window and the user can adjust settings.
So, I would be thinking along the lines of a single main window, "a control panel" with the buttons on the left and the options to the right of each button.
I would not be thinking about multiple toplevel windows, at least not from what you have described so far. MessageBox just pops up a window for the user to "click" upon and it is easy to use..No fancy TopLevel stuff involved.
The messageBox method to the mainWindow could work something like this (untested):
my $actions = "1)blah\n...2)blah\n...3)blah\n...4)\blah\n";
my $response = $mw->messageBox( -title => $STD_TITLE,
-message => "HEY!! This will do:\n $actions\n\n".
"DO YOU WANT TO PROCEED?\n\n",
-type => 'YesNoCancel');
print "yes clicked" if ($response =~/^Yes$/i); #of course you do it, n
+ot print
Another thing to consider with a GUI is: how you are going to present "progress" to the user? Of course assuming that whatever is being requested is going to take "some noticeable time".
I have often seen programs that:
-start zoomy animated .gif process that looks like progress is being made
-start "real work"
-stop zoomy animated .gif
The problem with this is that if "real work" hangs or lasts a very long time, the user doesn't know whether to cancel the program or wait some
more.
There are ways to make zoomy progress bars and also to present in the GUI: File #x processed as a periodically updated field. However, the easy way for this is to minimize the main window once the "actions" start being executed and just print something to STDOUT that represents "progress" (recommend more often than 5 seconds). If the main GUI window is minimized, the "command line" window will still be there. If that window is showing a different line every 5 seconds, the user will not CTL-C the application.
If you use printing to STDOUT for describing progress, if tester has problems, you can just have the tester start fancyGui.pl with a pipe to "tee", e.g. perl fancyGui.pl | tee SomeFile (or you provide some shell script like fancyGUI.bat) for error analysis and you will see where program "bombed".
|