[GRASS5] GUI sections and metadata or history graphs.

Michael Barton michael.barton at asu.edu
Fri Mar 10 10:36:10 EST 2006


What kind of information do you envision as coming out the the GUI guidance
section for use by a GUI?

Michael


On 3/9/06 7:39 PM, "Cedric Shock" <cedricgrass at shockfamily.net> wrote:

> 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.
> 
> 
> 

___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287

WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671




More information about the grass-dev mailing list