Making a program for a gui future

[o(o_o)o]

I'm stating to implement an idea of mine, and instead of making it Gui straight away, i am designing it to run on the command line.. so i run it, and it makes a prompt like:
myprompt->
myprompt->load file.dat
file loaded! myprompt->
where i give it commands etc...

the thing is, i want to design the program so that it can be fully used on the command line as i have just said... but want to make it possible to easily write a Gui frontend for it, hopefully with no editting of the current written program... so the Gui frontend would run the program and make changes and issue commands to it..

what i want is advice on how i would implement the command line program... would i just make it "print" and readline using <>, then grad those from the gui in the future, or is there a definiative way to write a command line program for a gui future?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i would slit my wrists for you

[simon.proctor]

If you are going to approach this properly then you I suggest that you need to consider the MVC or Model, View, Controller design. The functionality of your program can be split into these parts with a bit of thought and analysis.

The data your program operates on forms the model and provides methods to access, update and delete the information it contains. The controller is your main application. It provides all the glue logic for your app and also also looks after the interaction between the model and the views.

Finally, the view presents the user with their view of the program. However, your program can have as many of these as you like. Consider your program as having two views, command line and GUI. The underlying data and the basic logic is the same, the interaction with the user has changed.

In essence, you have decoupled your program model from your program display. The view then looks after the interaction between the user and the program, presents the info and makes calls (via the controller) to the model to get relevant data.

I suggest you look at the Observer pattern as a start point. Here (in very simplified terms) you can register objects to listen to events from another object. In context, you can register a view or views to listen to the model. When its state changes, it can notify the views. The view then grabs the info it requires and uses its own logic to display that to the user.

Hope that helps :)

[o(o_o)o]

Ah! I have been learning the Model, View, Controller design in my stupid Java lectures at Uni, but didn't know it was the same approach in Perl... are there premade Observer and Observable modules which can be <java speak>extended and implemented</java speak> in Perl, if there is, howcome i havn't heard much of them b4?

simon.proctor++, you sound like a lecturer ;-) thanks for your help, it makes a lot of sence now!! Thanks.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i would slit my wrists for you

[lachoy]

For posterity: I just uploaded Class::Observable which would likely be useful as infrastructure for this task.

Chris
M-x auto-bs-mode

[RMGir]

The main thing to do in order to make your program "guiable" is to separate out your action routines, so they can easily be driven from the gui.

For example, if you make "OpenFileByName" a sub, it won't matter if the gui drives it or the command line.
--
Mike

[Anonymous Monk]

I don't know about the gui-future part, but have you considered Term::ReadLine? I'm always a little annoyed when an interactive cmd-line program doesn't pick up my vi keys pref and doesn't do cmd history. Why not hook into libreadline and get all the goodies?

[blogan]

If you don't want the GUI right away, then just put a horrible GUI on it. Don't have stuff aligned, don't have nice fonts on the buttons, etc. It's going to be way easier to convert from a crappy GUI to a nice GUI then it will be from command line to GUI.