[GRASS5] GUI sections and metadata or history graphs.

[Cedric Shock]

Hello lawn gardeners,

If you are interested in either "GUI Sections" or a "Metadata Graph" I would 
greatly apreciate your comments.

Things I'm thinking about:

GUI Sections:

Add the following to the definition of both struct Option and struct Flag

This option would provide guidance for GUIs in arranging the options.
It can be multiple fields seperated by whatever delimiter is used most often 
that isn't a comma.
The gui could then lay out the options in tabs or group them with headers. A 
very smart gui might put each smallest section in its own box, calculate its 
height, then combine it with other options from the same next largest 
section, and if that's larger than the maximum height that the gui is trying 
to keep things under then split parts off into tabs.

These strings could be internationalized.

char *guisection;                /* GUI Layout guidance      */

This would allow the current TCL/TK interface or future GUIs to arrange things 
in a more handleable way. Any existing GUI should retain the option of 
displaying things the old style way.

This would require changes to:

include/gis.h
lib/gis/parser.c
general/g.parser/main.c
And to any file that ends up at:
$env(GISBASE)/etc/gui.tcl



Metadata Graph:

A metadata graph would keep track of everything that happens to data and would 
be able to provide a complete history of what happened to any map.

The following items would be tracked as nodes in the graph:

The graph could have the following types of nodes. *s are optional or perhaps 
undesired
	An issued command
	Versions of elements of named database things (versions of objects)
	Unique data nodes (anonymous regions, projection settings, etc)
	* A representation of external data (file, data in another location?, etc.)
	* Temporary files

These types of nodes would be considered root nodes for garbage collection. 
Anything not reachable from them can be removed from the graph.
	Versions of elements of named database things

The following would be tracked as subgraphs in the graph:
	Shell commands and other compound commands

Edges on graphs would be the following
	Edges point OUT TO where data came from.
	Edges can be labeled by the effect they had on the data (would require a 
module to label them). Expansion of what the parser does (database types, and 
io marking) would make this possible with less work for developers.

This would need to be hooked into the G_parser system, into commands that 
access data (G__open is fantastic and provides almost all the information we 
need), into commands that get significant (meaning altering) data from other 
sources (such as current region), and into programs that don't use these 
commands, such as the manage programs. It might to also be profitable to hook 
it into commands that write to the hist files.

One would also need to keep track of which nodes in the graph are associated 
with the current versions of files. This might be a new "element"

Edges need to go between mapsets

Garbage collection works like this:
Read in everything we're interested in (all users all mapsets). Mark 
everything that's reachable from any root nodes in any user's mapsets. Delete 
any node and edge in this user's this mapset that wasn't marked. It will only 
be done when called manually or possibly on exit.


What comes later is slightly less interesting,
--Cedric Shock


File format considerations:
All in one file - possibly too much overhead. It'd be nice to have bite sized 
files.
DGlib file format looks like it'd be expensive to write to.
DGlib is already part of grass; I should probably use it.
Graphs will need to be merged (across users and mapsets).
One file per node allows maximum access control to the graph.
One file per user allows just about the same control.
Something needs to give out unique node ids.


Places to insert hooks (procedures):
G_parser : Note the running of a program. Tentatively make command nodes
G__open : Note the opening of files. Commit to writing history graph nodes 
once somethign is opened in write mode.
G__get_window? / G_get_default_window / Whatever gets the current region and 
default region, assuming these aren't handled by G__open. We might want to 
handle regions seperately since not much data defines them.

include/gis.h
lib/gis/parser.c
general/g.parser/main.c
lib/gis/open.c

Modules that would need special attention:
 Anything that makes changes without going through open.c:
  general/managage/ all of these

 Anything that takes in important arguments or data not handled by G_parser:
  r.mapcalc (to describe expressions)

Ideas for commands:

G_history_graph_auto(On / Off): Call before G_parser to not have automatic 
histroy graph stuff done. Useful for commands with no side effects.

G_history_graph_auto_write(On / Off): Used to not have history graph writen 
automatically when a write operation is detected.

G_history_graph_write(): write the history now.

G_history_graph_add_edge (char* element, char* name, char* mapset, int mode): 
Add edges and nodes (when writing) to the history graph for versions of files 
involved.

More commands to add data to nodes that are around. Some commands that arn't G 
(not in gis.h) for querying and modifying the graph. Only commands for adding 
nodes to the graph should end up included from gis.h.

Then we'd need a small slew of programs for garbage collection, querying 
ascendants and descendants, output to formats like XML, graphvis, etc.