Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Making a program for a gui future

by o(o_o)o (Scribe)
on Mar 24, 2002 at 17:45 UTC ( #153916=perlquestion: print w/replies, xml ) Need Help??
o(o_o)o has asked for the wisdom of the Perl Monks concerning the following question:

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

Replies are listed 'Best First'.
Re: Making a program for a gui future
by simon.proctor (Vicar) on Mar 24, 2002 at 20:57 UTC
    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 :)

      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

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

        M-x auto-bs-mode

Re: Making a program for a gui future
by RMGir (Prior) on Mar 24, 2002 at 19:47 UTC
    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.

by Anonymous Monk on Mar 24, 2002 at 18:18 UTC
    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?
Re: Making a program for a gui future
by blogan (Monk) on Mar 24, 2002 at 22:54 UTC
    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://153916]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2018-06-25 06:34 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.