Think about what will happen as more tools get added to the given directory. Will you need to change the code in your GUI, or not? If yes, then you might want to think harder about how you are designing it. OTOH, if just changing your "metadata" is all that is needed to adapt the GUI to any change in the tool set, you still need to consider how that metadata is created and modified. Can (any of) that work be done automatically? (If yes, then you're on the right track.)

Personally, I view GUI interfaces to command-line tools as being sort of like training wheels on a motorcycle. I don't doubt that some people who've never used a motorcycle before may find some comfort in using them, at least for the first little while. But as soon as one has a basic grasp of using the unmodified mechanism, the training wheels slow it down and limit its use to the point of being an unbearable hindrance. (And many people just jump right on the unmodified machine and start moving.)

Still, there is real value in a GUI tool that can provide a good, comprehensive summary of other tools of any type. So focus on providing easy, sensible displays of the tools -- e.g. a listing that shows: tool name; availability of a man page; command-line usage synopsis; maybe even type of tool (shell script, perl script, binary, ...). Clicking on a list item should bring up the man page with more detailed explanation of usage, along with purpose, resulting output, and error conditions.

You might choose to provide a dynamic set of buttons based on the usage synopsis in order to activate particular options, but I think it's just as well to allow the user to type in a set of command line args. (The sooner they take off the training wheels, the sooner they'll speed up.)

If some tools have especially intricate controls, it would certainly be handy to have a simple method for storing a particular command+option string, with a label, for future use. (Among CL/shell addicts, this is known as creating an "alias" or "shell function".)

In reply to Re: Need feedback on a wrapper script design. by graff
in thread Need feedback on a wrapper script design. by selk

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.