[GRASS5] Ideas

Fri Sep 29 22:33:53 EDT 2000

> > In effect, the interface is written in an interpreted display
> > language.
> 
> This is what Tcl/Tk is. But unlike HTML, Tcl/Tk has a mechanism for
> interfacing with compiled C applications. The work that I will do will
> put all the interface generation code in Tcl/Tk scripts that will (just
> like your HTML version) be in text files that users can edit. Isn't this
> what you are suggesting only I am using Tcl/Tk instead of HTML? I don't
> see how our proposals are different except for the choice in GUI
> language.

Maybe they are identical, it depends on one thing: will the curses
interface use your Tcl/Tk scripts to build the curses interface
screens?  What I was thinking about is a separate file that describes
the dialog (maybe that is a better word?) that would be used by all
interfaces; curses, Tcl/Tk, web ...etc.  For example, the following
would be a HTML file describing the dialog for r.in.dem.  Notice that
there is no programming inherent in HTML that would link it to the grass
program (except maybe the ACTION command?).  The HTML would simply be
used, by whatever interface system, to display the dialog on the screen.

<HTML>
<HEAD>
<TITLE>r.in.dem - Import a DEM (Digital Elevation Model).
</TITLE>
</HEAD>
<BODY>
<FORM METHOD=POST ACTION="r.in.dem">
Input file name:        <INPUT TYPE=text NAME="filename" SIZE=32
MAXLENGTH=80><P>
Output raster map name: <INPUT TYPE=text NAME="outfilename"><P>
Spheroid:               <SELECT NAME="spheroid">      
                          <OPTION VALUE="sphere">sphere
                          <OPTION VALUE="APL4.9">APL4.9
                          <OPTION VALUE="CPM">CPM
                          <OPTION VALUE="GRS67">GRS67
                          <OPTION VALUE="IAU76">IAU76
                          <OPTION VALUE="MERIT">MERIT
                          <OPTION VALUE="SEasia">SEasia
                          <OPTION VALUE="...etc."> I didn't want to type
them all  :-)
                        </SELECT><P>
Resolution: East/West   <INPUT TYPE=text NAME="ew_res"><P>
Resolution: North/South <INPUT TYPE=text NAME="ns_res"><P>
Size: Rows:             <INPUT TYPE=test NAME="rows"><P>
Size: Columns:          <INPUT TYPE=test NAME="columns"><P>
<INPUT TYPE=submit><P>
A typical 7.5 minute U.S.G.S DEM has ? rows, ? columns and a uniform
resolution of ?.  I am making this section up.  The point is that you
could have help, notes, hints,...etc.  Also a <A
HREF="r.in.dem.html">link to the HTML help.</A>
</FORM> 
</BODY>                                                                         
</HTML>

That's it.  The interface system (curses, Tcl/Tk, ...whatever) would be
responsible for parsing, display, and collection of user inputs.

Now, the problems that have cropped up as I have thought about this. 
How do you handle input sanity checks?  With a web browser you use
JavaScript which would be much too big.  I have thought of a couple
other ways, but none of them elegant.  What about large tables, like
what happens with r.reclass?  No solution to that either.  Maybe XML
would be a better dialog builder?

Anyway, that is one of the things that I was thinking about.

take care
tim cera

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'