[GRASS5] proposal for a grass command interface descriptionforautomatic GUI building

Andreas Lange Andreas.Lange at Rhein-Main.de
Fri Oct 27 13:36:28 EDT 2000


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 :-)
> 
> 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 at Rhein-Main.de - A.C.Lange at GMX.net


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



More information about the grass-dev mailing list