Divorcing Command Line and GUI

[David Bolen]

Harry George <hgg9140 at cola.ca.boeing.com> writes:

> A couple of options:
> 
> 1. The Model-View-Controller pattern, where the model is your
> underlying application engine and you have two views: commandline and
> gui.
> 
> You will probably need as abstract "user interface" class which
> defines the available callbacks, and then subclass the comline and gui
> off that.  In the abstract case, you need ways to let the engine get
> the data it wants (modal dialogs), and for the ui to trigger actions
> in the engine (modeless actions).  

Or if you don't want to go the whole MVC setup, Python is still
extremely friendly to having a shared module between command line and
GUI parent modules, and even in general to embed the command line code
right with the main module.

All of the functions within a module can be treated essentially as
methods of that module object, when that module is imported by
another.  So if, for example, you've got a module that has a small
entry point (within the if __name__ == "__main__" block) that just
handles the command line and then executes via other functions/classes
in the module, your GUI can just import that top script and then
directly call the methods as appropriate - bypassing the block used
from the command line.

It can be pretty simple to design a module this way such that it runs
fine from the command line, but under a GUI, it's imported and its
functions used directly as dictated by the GUI.  You don't need to
worry as much about callbacks and what not this way since the module
is just providing support code used by the GUI.  Although depending on
the code involved, you may still separate out much of the action from
your main GUI thread for performance reasons.

The really neat thing is that while you can make this really effective
if you've designed with this in mind from the beginning, it can be
amazingly effective even with random Python scripts that you never
originally thought would be used as modules by later scripts.  About the
only place you can hurt yourself is by placing too much true script
application logic in the if __name__ block, or if you place command
line logic outside of such a block.

> 2. Keep the comline app as is.  Run it from the gui (e.g., via pipes).

And this case doesn't necessarily have to imply that the user even
knows that the raw command line tool is running beneath the scenes.
You can trap all of the output from the command line application and
parse/massage it into some other format for inclusion in the GUI.  If
not normally that friendly for parsing, you can always add a hidden
option to the command line tool to produce its output in a
parsing-friendly way.

Of course, you can also just re-route all of the output from the tool
into a common GUI element like a text or list box just for display
purposes.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/