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".


In reply to Re^5: GUI for Test suite by Marshall
in thread GUI for Test suite by dpatel

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.