[GRASS5] proposal for a grass command interface description for automatic GUI building

GRASS GRASS developer
1

Dear GRASS developers,

I am developing a bridge between GRASS commands and OSSIM together with
Frank Warmerdam and Bernhard Reiter.

I am currently working on GRASS forms descriptions that
define command options and arguments of GRASS commands
with associated information. These forms can be used
to automatically build simple GUIs for entering values
and launching the GRASS commands.

My main ideas for the way to go are

  * GRASS programs can be asked for the parameter description
  * parameter description is based on XML.

Why XML?

I don't like the idea to develop just another text based format
for a specific task. A simple XML approach will do it as well
and opens up further opportunities.

We don't need a comprehensive XML parser in a first approach.
Producing XML is easy. Writing simple parsers should be of reasonable effort.
So linking against a xml library is not required though IMO any
large software package will do this sooner or later at least for some
import/export functionality.

One idea I like very much:
There are several projects starting to describe user interfaces based
on XML. So, if we have a parameter description based on xml, a simple
xsl transform can be developed and would lead to nice dialogs for any
widget toolkits (static or on the fly!).

Thats the future. What can we achieve right now?

With the Option and Key structures we have a base to produce the forms.
I have modified parser.c to accept a special parameter for generating
xml specification:

GRASS:~ > r.basins.fill --task-description
<task name="r.basins.fill">
  <parameter-group>
    <parameter name="number" type="integer" required="yes">
      <description>
        Number of passes through the dataset
      </description>
    </parameter>
    <parameter name="c_map" type="string" required="yes">
      <description>
        Coded stream network file name
      </description>
    </parameter>
    <parameter name="t_map" type="string" required="yes">
      <description>
        Thinned ridge network file name
      </description>
    </parameter>
    <parameter name="result" type="string" required="yes">
      <description>
        Name for the resultant watershed partition file
      </description>
    </parameter>
  </parameter-group>
</task>

Option lists are not implemented yet. I am thinking on a tag
(of <parameter>) as such:
<values>
  <value>option 1</value>
  <value>option 2</value>
</values>
or
<values>
  <range min="0.5" max="1.5"/>
  <range min="2.5" max="3.5"/>
</values>

Already implemented is:
<default>
  3.4
</default>

What would also be nice for <task> is:
<version>1.12</version>
and
<authors>
  <author>Gary Grassdeveloper</author>
</authors>

So there are many ideas ... :slight_smile:

What do you think about this approach? Comments?
Have I missed something?

The plans for the GRASS bridge to OSSIM include a parsing of the
GRASS command forms for wxWindows. It should be fairly easy for
tcltkgrass as well since there is already a parser currently based
on tcl list structure.

Attached is my patch for parser.c.

Cheers

  Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

(attachments)

parser.c.diff (2.45 KB)

2

Jan-Oliver Wagner wrote:

With the Option and Key structures we have a base to produce the forms.
I have modified parser.c to accept a special parameter for generating
xml specification:

GRASS:~ > r.basins.fill --task-description
<task name="r.basins.fill">
        <parameter-group>
                <parameter name="number" type="integer" required="yes">
                        <description>
                                Number of passes through the dataset
                        </description>
                </parameter>
                <parameter name="c_map" type="string" required="yes">
                        <description>
                                Coded stream network file name
                        </description>
                </parameter>
                <parameter name="t_map" type="string" required="yes">
                        <description>
                                Thinned ridge network file name
                        </description>
                </parameter>
                <parameter name="result" type="string" required="yes">
                        <description>
                                Name for the resultant watershed partition file
                        </description>
                </parameter>
        </parameter-group>
</task>

Jan-Oliver,

I really like the fact that these descriptions can be established from the
existing information provided by the programmer to the parser.

I read over the section of the programmers manual on the parser, and I see
there is alot more capability there than I had known. I would encourage
folks interested in this issue to carefully review all of section 15.16 in
the manual.

Some items apparently supported by the parser, but not mentioned by you
are:

o The key_desc field of the Option structure apparently allows the
   program to descibe an arguments format to some degree. For
   instance a location might have a key_desc of "x,y", and apparently
   the parser uses this to put two separate items into "answers"
   after parsing, and presumably to prompt the user accordingly.

   Is this used? Perhaps we should capture this information to
   support a more rigerously checked forms interface.

o The multiple field apparently indicates whether the user can
   give multiple answers for an option.

o The Gisprompt field can be used to control prompting for particular
   items like an existing raster layer, or a new vector name. I think
   capturing this is critical so that the generated form can provide
   comparible prompting in the form of pick lists and so forth.

o There is a Checker field where programs can register validation
   functions for parameters. This doesn't appear to be described any
   further. I presume it isn't used much? For programs that do alot
   of programatic validation of parameters after G_parser(), it may be
   helpful to move some of that into the Option and then a forms based
   application could launch the program in a special non-interactive mode
   that just validates the parameters. This is likely not worth pursuing
   on the first pass.

It seems likely that once we start generating forms automatically we will
discover that many programs have not fully utilized the above options to
inform the parser of the program arguments definitions, and that we will
have to patch them up a bunch. This should be helpful even for traditional
use of the programs.

We should (I think) also keep our minds open to the possiblity of extending
the Option structure if necessary to return additional useful information.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerda@home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

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

3

On Fri, Oct 20, 2000 at 02:32:32PM -0500, Frank Warmerdam wrote:

I read over the section of the programmers manual on the parser, and I see
there is alot more capability there than I had known. I would encourage
folks interested in this issue to carefully review all of section 15.16 in
the manual.

Some items apparently supported by the parser, but not mentioned by you
are:

o The key_desc field of the Option structure apparently allows the
   program to descibe an arguments format to some degree. For
   instance a location might have a key_desc of "x,y", and apparently
   the parser uses this to put two separate items into "answers"
   after parsing, and presumably to prompt the user accordingly.

   Is this used? Perhaps we should capture this information to
   support a more rigerously checked forms interface.

I've seen it used in one or two places. Essentially defines a "tuple".

o The multiple field apparently indicates whether the user can
   give multiple answers for an option.

Several modules use this.

o The Gisprompt field can be used to control prompting for particular
   items like an existing raster layer, or a new vector name. I think
   capturing this is critical so that the generated form can provide
   comparible prompting in the form of pick lists and so forth.

This is usually used for input/output file validation
(noclobber/existence checks). Also widely used, and should be used
whenever possible.

o There is a Checker field where programs can register validation
   functions for parameters. This doesn't appear to be described any
   further. I presume it isn't used much? For programs that do alot
   of programatic validation of parameters after G_parser(), it may be
   helpful to move some of that into the Option and then a forms based
   application could launch the program in a special non-interactive mode
   that just validates the parameters. This is likely not worth pursuing
   on the first pass.

Haven't seen anything using this. Most modules I've looked at do there
checking after the call to G_parser(). You can't check for interactions
between parameters (or things that won't be known until after a "file"
is opened). And, you still will have to convert the parameter later
(though the TYPE_<foo>) macros should catch wrong type arguments (??)).

It seems likely that once we start generating forms automatically we will
discover that many programs have not fully utilized the above options to
inform the parser of the program arguments definitions, and that we will
have to patch them up a bunch. This should be helpful even for traditional
use of the programs.

We should (I think) also keep our minds open to the possiblity of extending
the Option structure if necessary to return additional useful information.

My general thoughts are, modules could be turned into little mini
libraries (and dlopen'ed) if all main.c and main() did was pass
validated arguments to a function defined in another file. Then the
files/functions the do the work could be separated into little shared
libraries like 's.to.rast.so.5.0.1'. I'd think it'd make writing GUI's
easier and it'd minimize the use of things like system() which can't
return much useful information. Just a thought.

AFAIK, glade uses an XML file for libglade (just an example). There's
also this ENTITY thing, but it's still pretty early development.

--
/bin/sh ~/.signature:
Command not found

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

4

Jan-Oliver Wagner wrote:

My main ideas for the way to go are

        * GRASS programs can be asked for the parameter description
        * parameter description is based on XML.

This is great! I would add one additional criteria. That the XML is
kept in a seperate file so that changes could be made to the interface
without re-compiling. Something like
$GISBASE/task_description/r.basins.file.xml. This would allow very
rapid language changes (German, French, ...etc.) and user customizations
- just replace/edit the XML files.

Any developed interface systems should use the --task_description (I
changed the internal "-" in your original message to an "_") instead of
the raw XML. Maybe --interface_description, since a user will probably
never type it? And then change the XML directory name to match.

take care
tim cera

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

5

Hi Jan-Oliver,

your proposal sounds very interesting.

I have only to add that some modules in GRASS 5.0 need updating/fixing
to work as expected.

First there should be some standardization on the interface, eg. we have
to define when to use "file=" and when "input= output=" etc.
This is not required for the XML parsing, but for the user. And should
be done as soon as possible.

Next i found that some modules are not build in/to the correct location:
All binaries that are interactive should go into $(BIN_MAIN_INTER) (=
etc/bin/main/inter), command line versions should go into
$(BIN_MAIN_CMD) (= etc/bin/main/cmd), programs that provide both
functions must get a program that switches beween both versions in bin.

If you find modules that do not work as expected, please tell me as i
will try to update them (already fixed g.setproj).

cu,

Andreas

Jan-Oliver Wagner wrote:

Dear GRASS developers,

I am developing a bridge between GRASS commands and OSSIM together with
Frank Warmerdam and Bernhard Reiter.

I am currently working on GRASS forms descriptions that
define command options and arguments of GRASS commands
with associated information. These forms can be used
to automatically build simple GUIs for entering values
and launching the GRASS commands.

My main ideas for the way to go are

        * GRASS programs can be asked for the parameter description
        * parameter description is based on XML.

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

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

6

Hi Tim,

On Mon, Oct 23, 2000 at 07:28:45AM -0500, Tim Cera wrote:

Jan-Oliver Wagner wrote:
> My main ideas for the way to go are
>
> * GRASS programs can be asked for the parameter description
> * parameter description is based on XML.

This is great! I would add one additional criteria. That the XML is
kept in a seperate file so that changes could be made to the interface
without re-compiling. Something like
$GISBASE/task_description/r.basins.file.xml. This would allow very
rapid language changes (German, French, ...etc.) and user customizations
- just replace/edit the XML files.

Thats the way it is currently done for tcltkgrass.
One disadvantage is that you have a higher maintenance effort in case
you change a parameter name or add/delete one or add a new GRASS command.

If you are looking at the localization: To my mind, the language must be
incorporated already within the GRASS commands. They will (provided the
translation has been done) then speak your language in the command
line version as well as the GUI. Perhaps we'll have .po-files for most
languages for GRASS one day. It is a major effort and we should optimize
the work on this.

Any developed interface systems should use the --task_description (I
changed the internal "-" in your original message to an "_") instead of
the raw XML. Maybe --interface_description, since a user will probably
never type it? And then change the XML directory name to match.

First of all I like the '-' instead of '_' since it is the GNU style.
Perhaps we can adopt the GNU parser for the command line...

I regard GRASS commands task-oriented. I intentionally used the term 'task'
for the corresponding XML tag to later have the option to put together
many <task ..> (including perhaps some <task-group ...>)
to a complete <interface ...> definition which would define a whole
GRASS application.

However, if you like --interface-description I can use that as well.
Right now we have the freedom to choose. Later on it will be difficult
to change.

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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

7

Hi Andreas,

On Tue, Oct 24, 2000 at 12:18:35AM +0200, Andreas Lange wrote:

I have only to add that some modules in GRASS 5.0 need updating/fixing
to work as expected.

The user interface description would benefit from some face lifting
within the GRASS commands. I'll need to go through a number of commands
(for the grass-ossim bridge I will focus on raster commands)
and look for problems.

First there should be some standardization on the interface, eg. we have
to define when to use "file=" and when "input= output=" etc.
This is not required for the XML parsing, but for the user. And should
be done as soon as possible.

I have seen the recent postings about this issue. The standardization
would benefit any kind of GRASS user interface.
I am really happy to see people work on this matter.

If you find modules that do not work as expected, please tell me as i
will try to update them (already fixed g.setproj).

Sure :slight_smile:

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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

8

Dear Tim,

On Thu, Oct 26, 2000 at 07:25:27AM -0500, Tim Cera wrote:

Jan-Oliver Wagner wrote:
> Thats the way it is currently done for tcltkgrass.
> One disadvantage is that you have a higher maintenance effort in case
> you change a parameter name or add/delete one or add a new GRASS command.

Yes, I had noticed the tcltkgrass setup. Excellent design.

How often is a parameter name changed or a new GRASS command added?

it looks like that will be quite extensively the case in the near future
due to the aspired parameter harmonization :slight_smile:

Later on that will happen not often, but frequently enough to make it a pain
for the programmers to keep in mind changing the parameter definition
at several places. Look at tcltkgrass: It is out of date for several commands.
Name changes are detected by some users quickly, but how about new parameters?

> If you are looking at the localization: To my mind, the language must be
> incorporated already within the GRASS commands. They will (provided the
> translation has been done) then speak your language in the command
> line version as well as the GUI. Perhaps we'll have .po-files for most
> languages for GRASS one day. It is a major effort and we should optimize
> the work on this.

I have seen the .po files for only one other application. I still
propose separate XML files as this gives significant power to the user.
There could be tarballs of different languages that you just untar into
the interface directory.

I think the command line interface should use the XML also. Instead of
having I/O commands hard coded in each command, a parser should be
called that would read the XML, collect user input, return appropriatly
set variables.

The information on how a componenent works and what it needs is
necessarily an integral part of the component itself.
If you make the component load an external file with its
interface description, it still needs to check whether
it is compatible with its actual capabilities. You need
error handling etc.
To my mind the interface specification should be generated from
the place where the interface is actually coded.
Only this way overall consistency is guaranteed.

For the language: I estimate that the GRASS community has
the wish for say 10 languages. We have more than 400 commands
so we need to manage and take care for over 4000 xml-files to have
a consistent user interface.
hm, possible, but I would like to have it more simple.
We really should not mix languages and user interface descriptions.

Which advantages for users do you mean to gain by seperate user interface
description files? Perhaps I am missing something. (I don't have learned
about any facet of GRASS yet; its just a too mighty dragon :wink:

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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

9

Hi Tim, Hi Jan-Oliver,

i personally think that it would be better to keep most things in one
place, i. e. keep the interface description with the module. Programmers
do not want to change something that could be generated automatically by
hand IMHO. It is already very complicated that the documentation is in
external html-files in a central directory (though it is an improvement
that no nroff-man pages have to be supplied any longer). Updating
tcltkgrass is a lot of work and should be automated. I already supplied
functions to read in the ellipse.table, fonts table and other
configurable files on startup of tcltkgrass.
We could cache the interface descriptions, e. g. with a script that
re-generates the files on re-compiling or adding a module.

Another proposal: I think it would be very useful if the module itself
has some information about the name and the purpose of the module (I am
myself often clueless what a module is exactly for). Like the title line
of the tcltkgrass-modules. This could be used for searching and in
display/entry windows. It should be possible to simply add this to the
grass parser, even if the modules do not use it currently. We could
later incorporate the information from the tcltkgrass-module-files into
the modules (like my = G_define_title(); my->title="n.osuch.module";
my->descr="this module has no specifically purpose";
my->author="Andreas"; ...).

I believe that the module concept of grass has many advantages, but one
inherent problem is that everything is centered around the tasks/steps
to be performed on the data, not on the data itself. The modules name is
the only "key" from some needed functionality to the module to be used
to get the functionality. This could be improved by something like a
(searchable) methods/functionality database. The html-manual is often
not much of a help, because it is sorted by module-name and sometimes
the described functionality differs from the module implementation
(improved very much recently!).
I have the impression that Markus had something similar in mind when he
wrote the proposal for the new directory structure of grass5.1 (compare
documents/new_directory_structure.txt). But i fear that sorting the
source code of the different modules to new directories is not much
improvement (e. g. raster modules are easily recognizable by first
letter r etc.). Something on a higher level is needed IMHO. I must admit
that i am not familiar with CORBA/IDL, so i am not able to make specific
suggestions here.

We should discuss this further on this list, but i am concentrating on
bugfixing for the stable release right now.

cu,

Andreas

Jan-Oliver Wagner wrote:

Dear Tim,

On Thu, Oct 26, 2000 at 07:25:27AM -0500, Tim Cera wrote:
> Jan-Oliver Wagner wrote:
> > Thats the way it is currently done for tcltkgrass.
> > One disadvantage is that you have a higher maintenance effort in case
> > you change a parameter name or add/delete one or add a new GRASS command.
>
> Yes, I had noticed the tcltkgrass setup. Excellent design.
>
> How often is a parameter name changed or a new GRASS command added?

it looks like that will be quite extensively the case in the near future
due to the aspired parameter harmonization :slight_smile:

Later on that will happen not often, but frequently enough to make it a pain
for the programmers to keep in mind changing the parameter definition
at several places. Look at tcltkgrass: It is out of date for several commands.
Name changes are detected by some users quickly, but how about new parameters?

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

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

10

Jan-Oliver Wagner wrote:

> I think the command line interface should use the XML also. Instead of
> having I/O commands hard coded in each command, a parser should be
> called that would read the XML, collect user input, return appropriatly
> set variables.

The information on how a componenent works and what it needs is
necessarily an integral part of the component itself.
If you make the component load an external file with its
interface description, it still needs to check whether
it is compatible with its actual capabilities. You need
error handling etc.
To my mind the interface specification should be generated from
the place where the interface is actually coded.
Only this way overall consistency is guaranteed.

Good point. Could the command line interface still use the XML by
calling --interface-description? That sounds kinda messy ... ah
nevermind.

For the language: I estimate that the GRASS community has
the wish for say 10 languages. We have more than 400 commands
so we need to manage and take care for over 4000 xml-files to have
a consistent user interface.
hm, possible, but I would like to have it more simple.
We really should not mix languages and user interface descriptions.

That is why XML has such great advantages. There could be a XSL file
with a lot of the interface stuff, and XML with the text.

Which advantages for users do you mean to gain by seperate user interface
description files? Perhaps I am missing something. (I don't have learned
about any facet of GRASS yet; its just a too mighty dragon :wink:

My day job is at an ESRI only shop and they have developed a whole suite
of local changes via Avenue, AMLs, ...etc. Say a GRASS admin wanted to
include some help with a particular command that is specific to that
organization. Just edit the XML. Not a huge advantage. The best
reason is still easy internationalization.

Something new. It would be nice to have a 'Help' button that is
described in the XML and will open up the man page. I sure can find
work for you! :slight_smile:

take care
tim

timcera@earthlink.net
http://home.earthlink.net/~timcera

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

11

Hi Tim, Andreas, Jan-Oliver,

On Fri, Oct 27, 2000 at 07:36:28PM +0200, Andreas Lange wrote:

Hi Tim, Hi Jan-Oliver,

i personally think that it would be better to keep most things in one
place, i. e. keep the interface description with the module. Programmers
do not want to change something that could be generated automatically by
hand IMHO. It is already very complicated that the documentation is in
external html-files in a central directory (though it is an improvement
that no nroff-man pages have to be supplied any longer).

I apologize if this centralization is not the best idea. Well,
the current status is that we have it *now* all centralized and
obsolete (man) stuff removed. Maybe we decide to spread the descritions
later again, probably with a format change (not html). Then the local
makefiles need an entry to generate the page and copy to a central
place (for takeaway for the web server).
Of course I am open to other ideas. HTML may be just a step in between!

Updating
tcltkgrass is a lot of work and should be automated. I already supplied
functions to read in the ellipse.table, fonts table and other
configurable files on startup of tcltkgrass.
We could cache the interface descriptions, e. g. with a script that
re-generates the files on re-compiling or adding a module.

Yes, probably the parser.c can talk "tcl" as well to generate the
module descritions needed by gui.tcl/menu.tcl.

Another proposal: I think it would be very useful if the module itself
has some information about the name and the purpose of the module (I am
myself often clueless what a module is exactly for). Like the title line
of the tcltkgrass-modules. This could be used for searching and in
display/entry windows. It should be possible to simply add this to the
grass parser, even if the modules do not use it currently. We could
later incorporate the information from the tcltkgrass-module-files into
the modules (like my = G_define_title(); my->title="n.osuch.module";
my->descr="this module has no specifically purpose";
my->author="Andreas"; ...).

Again I highly agree. This is indeed a missing function which might be
added easily. Maybe we can later put in at least the "my->descr" by
an intelligent PERL script:
- search the HTML page, extract the one-line description,
- search main.c, add in appropriate place
(o.k., just dreaming).

I believe that the module concept of grass has many advantages, but one
inherent problem is that everything is centered around the tasks/steps
to be performed on the data, not on the data itself. The modules name is
the only "key" from some needed functionality to the module to be used
to get the functionality. This could be improved by something like a
(searchable) methods/functionality database. The html-manual is often
not much of a help, because it is sorted by module-name and sometimes
the described functionality differs from the module implementation
(improved very much recently!).

A nice and easy search engine can be found within "R":
http://stat.ethz.ch/R-alpha/doc/html/search/SearchEngine.html
(based on JAVA). It is shipped with R and runs locally as well.

I have the impression that Markus had something similar in mind when he
wrote the proposal for the new directory structure of grass5.1 (compare
documents/new_directory_structure.txt). But i fear that sorting the
source code of the different modules to new directories is not much
improvement (e. g. raster modules are easily recognizable by first
letter r etc.). Something on a higher level is needed IMHO. I must admit
that i am not familiar with CORBA/IDL, so i am not able to make specific
suggestions here.

We should discuss this further on this list, but i am concentrating on
bugfixing for the stable release right now.

Yes, should be multitasking :slight_smile:

Still some severe bugs are there to be fixed:

- CELL driver not yet 24bit
- r.null: does not work with reclassified maps
- r.reclass: does not accept "*" to reclass NULL values

and others in BUGS

Regards

Markus

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

12

Hi Andreas,

On Fri, Oct 27, 2000 at 07:36:28PM +0200, Andreas Lange wrote:

Another proposal: I think it would be very useful if the module itself
has some information about the name and the purpose of the module (I am
myself often clueless what a module is exactly for). Like the title line
of the tcltkgrass-modules. This could be used for searching and in
display/entry windows. It should be possible to simply add this to the
grass parser, even if the modules do not use it currently. We could
later incorporate the information from the tcltkgrass-module-files into
the modules (like my = G_define_title(); my->title="n.osuch.module";
my->descr="this module has no specifically purpose";
my->author="Andreas"; ...).

Yes, a good point. It would support the automatic GUI creation.

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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

13

Hi Markus,

On Sat, Oct 28, 2000 at 03:36:44PM +0100, Markus Neteler wrote:

> Updating
> tcltkgrass is a lot of work and should be automated. I already supplied
> functions to read in the ellipse.table, fonts table and other
> configurable files on startup of tcltkgrass.
> We could cache the interface descriptions, e. g. with a script that
> re-generates the files on re-compiling or adding a module.
Yes, probably the parser.c can talk "tcl" as well to generate the
module descritions needed by gui.tcl/menu.tcl.

Making the parser talk tcl would mean to have it speak two
languages (xml and tcl). I think it is better to have tcltkgrass
speak xml, so it can parse the user interface description.

In the current tcl user interface descriptions there is some more
information than the modules themselves can provide (e.g. short description).
Once we make al modules know such things, we could get rid of the
extra tcl-based UI descriptions and use the output of --interface-description
as well.

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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

14

Dear Tim,

On Fri, Oct 27, 2000 at 10:40:51PM -0500, Tim Cera wrote:

Something new. It would be nice to have a 'Help' button that is
described in the XML and will open up the man page. I sure can find
work for you! :slight_smile:

Hope you don't mean just myself personally.
There are lots of GRASS developers to implement all
these nice ideas :slight_smile:

However, I will first make sur that the base functionality
works fine. Andreas already found some problems.

Cheers

  Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

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