Divorcing Command Line and GUI

[Harry George]

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

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

Timothy Grant <tjg at exceptionalminds.com> writes:

> Hello Everyone.
> 
> This is something of a strange question, but please bear with
> me.
> 
> I have a series of tools that I have created that work from the
> command line. I have now been tasked with creating GUIs for
> those tools. The problem I'm faced with is that the command
> line tools and the GUI tools will probably be licensed
> differently (e.g, command line will be Open Source, GUI will be
> something undetermined as of yet.) This means that I can't put
> my GUI code in with my CL code.
> 
> My first cut at this demarcation sort of worked, but was also
> troublesome. So while I have some new ideas, I'm looking to see
> if anyone else in the python community has ever had to do
> something like this, and if there are any easily maintainable
> solutions to this problem.
> 
> 
> 
> -- 
> Stand Fast,
>     tjg.
> 
> Timothy Grant                         tjg at exceptionalminds.com
> Red Hat Certified Engineer            www.exceptionalminds.com
> Avalon Technology Group, Inc.         <><       (503) 246-3630
> >>>>>>>>>>>>>Linux, because rebooting is *NOT* normal<<<<<<<<<
> >>>>This machine was last rebooted:  51 days 22:09 hours ago<<
> 

-- 
Harry George                E-mail:  harry.g.george at boeing.com
The Boeing Company          Renton:  (425) 237-6915
P. O. Box 3707  02-CA       Everett: (425) 266-3868
Seattle, WA 98124-2207      Page:    (425) 631-8803