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

[Jan-Oliver Wagner]

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?

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

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