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

[Markus Neteler]

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

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'