[GRASS-dev] GRASS7 wish

David Finlayson david.p.finlayson at gmail.com
Fri Jun 16 04:12:54 EDT 2006


Glynn -

I think we misunderstood each other. What I want is a simple method
for a grass program to describe itself to ANOTHER program.

Ideally, the user-interface (whether GUI or Text) of each binary and
script would be built by parsing the resource file for input and
output requirements (flags, etc.).  Also, the console help and HTML
manual pages would be built directly from the resource file.

I think if the resource file were tightly integrated to both the user
interface of the program and the derivative products like console help
and html manual pages, we would get better synchronization rather than
the reverse.

I think the format used by g.parser is pretty good. It just needs a
few extra fields for storing the long help (what would go in the
manual page). On the other hand, if we used some kind of xml file, we
might be able to slap a stylesheet on top and display the resource
file directly as the manual page. That would be a great
synchronization benefit.

David

On 6/15/06, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> David Finlayson wrote:
>
> > As part of my Pythonification of grass project, I'd like to add to our
> > GRASS 7 workload:
> >
> > Would it be useful to have metadata about our scripts and programs?
> > Basically, what I propose is a simple text file that describes each
> > command and script in a standard format. I like the format that
> > g.parser uses in sh scripts today. I would extend it to include a
> > short help and long help description and a sort-of 'magic cookie'
> > which describes how to launch the script/program.
> >
> > g.parser would be adjusted to read the resource file so there would be
> > no user-visible changes. HTML documentation would be built using the
> > resource file and an HTML template. GUI's could build their GUI code
> > based on the resource file.
>
> If you need more information about a module, extend the Module, Flag,
> or Option structures to contain the relevant information, and update
> the relevant functions in lib/gis/parser.c to use that information.
>
> Having separate metadata files creates a risk of those files getting
> out of sync with the actual modules.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>


-- 
David Finlayson




More information about the grass-dev mailing list