[GRASS5] Proposal for GRASS UI roadmap

Maciek Sieczka werchowyna at epf.pl
Sun Nov 6 07:50:05 EST 2005


Michael,

Thanks for your initiative. I hope it will make a good start for new
Grass GUI. I think that a native, Grass dedicated GUI for is necessary.
I'm adding my point of view on several points.

On Sat, 2005-11-05 at 21:59 -0700, Michael Barton wrote:

<snip>

> DISPLAYS
> 
> ***Display windows: 
> Keep ability to have multiple display windows. Display should have the
> potential to display both 2D and 3D graphics. Display windows should
> get focus by clicking with mouse. It should be necessary to run a
> module like d.mon select simply shift the focus to a different display
> window.


> ***2D and 3D visualization:
> 2D and nD visualization should be seamlessly integrated. The "normal"
> view would be 2D like current x displays and standard GIS. Clicking a
> 3D (nviz) button would open a floating window with 3D controls (like
> in nviz now) but not a new display window.

Hmm, why not a separate window? I'd prefer:
1. display contents in the 2D window, or select a an existing window
with some layers displayed
2. press the 3D button
3. 3d window with the same layers and controls pop up
4. the 2D window is left untouched - now user can compare the 3D and 2D
view now, use the 2D display as "map", context for navigation in the 3D


>  This would allow user to tilt, rotate, change z, visually separate
> layers, etc. It would work with the same layers shown in 2D mode, but
> would simply display them in 2.5D or 3D. Nviz would not be a separate
> module, opening a separate display window and separate layer control
> panel; it would simply display any active layers in 3D "mode". 
> 

> DISPLAY CONTROL GUI AKA GIS MANAGER
> 
> We should keep single display control (like current GIS Manager).
> distinct from the  display window(s). This allows for multiple display
> windows to be controlled from single interface. Display "commands"
> should be integrated into display control interface; there would be no
> separate d.* command modules. That is, the display control system
> should be able to directly draw graphics to a display window, without
> going through intermediate, stand alone programs. We need to rethink
> how these would best be implemented (e.g., should we combine thematic
> vector and chart display functions?) Display functions should still be
> scriptable as in nviz and d.m, just not independent "commands". It
> should be possible to run a display script from the command line to
> automate mapping.
> 
> ***Buttons:
> There should be 1 row of buttons for display controls (zoom, pan,
> erase, 3D, query, layer management, open display window, save, print,
> etc). We should change current display in region buttons to simply
> region setting buttons (default, select saved region). We will no
> longer need a display button (see layers specs below)

> There should be a 2nd row of buttons for adding layers. This could be
> space-optimized by making pull-down groups (e.g., vector group would
> include vector, 3D vector, chart, thematic, etc) with last-used
> layer-type showing up in the button bar.
> 
> ***Layers: 
> Any function than can be thought of as a layer should be implemented
> as one. It is a nice and pretty intuitive metaphor. It is easy to work
> with conceptually and comparable to graphic and CAD programs. Layers
> should include 3D vectors and volumes (see below) along with the kinds
> of layers now in the GIS manager. 
> 
> We should keep layer-tree metaphor. The hierarchical arrangement is
> intuitive and easy to work with. Nested groups are an especially nice
> touch. We may want to switch from arranging the layer in the order
> they will be displayed (first at the top, last at the bottom), to a
> stacked metaphor (last displayed at the "top" of the stack). This is
> more in line with other GIS programs and most graphics programs, and
> would make GRASS less confusing to a new user.


I like the stack-approach too, but I'd prefer a new layer/grop to be
added exactly on top of the currently highlited one. Having to move it
manually to it's destination *each time* I add a new one is a pain.

I know it would be not 100% solution - in case it is needed to put the
layer/group right at the end of the stack, one will have to move it by
hand. Anyway, still better than having to do so each time.

> Adding a layer to the layer tree should automatically display it when
> the 'active' box is checked. There should be no need for display
> button. Checking or unchecking the 'active' box should automatically
> display  or undisplay the layer. Should layers be added in an
> non-activated state by default so that the user can choose to display
> the newly added layer when ready?

The 'active' box idea is nice. And I think it should be set to 'off' by
default. Otherwise adding heavy raster layers, or vector layers with
many objects, would be slow, as each layer would have to be drawn first,
as currently Grass is not able to draw multiple layers simultanously.
> 
> There should be an independent layer tree for each display window
> open. Selecting display window with the mouse displays the associated
> layer tree. This permits multiple displays of different information
> controlled from same interface. User should be able to copy existing
> layer tree to a new or open display window.

Also, it should be possible to mark and copy/cut/paste and remove
multiple layers or gropus. Currently it is quite a hassle when one wants
to remove 50 of his 100 layers :D.

> ***Option panes:
> Option panes should open in a separate window when an entry in the
> layer tree is double clicked. This will optimize space in the display
> control GUI. There should be "apply" and "save and close" buttons so
> that an option pane can be kept open if desired.

Great.
> 
> We should add a "layer name" field to the option pane rather than
> adding a layer name by typing it into the layer tree. This makes it
> more "permanent" so that it is not erased when a new map is chosen to
> be displayed in that layer. If it is empty, the name of the map will
> go in by default; if something has been typed in it, it will stay and
> not be overwritten (make this a question when opening a file?)

My POV: default the layer name to the file name, allow to edit it later.
Having to answer a question at each layer addition would slow down the
user for no purpose. Also I believe the layer name should change each
time when another file is open in the layer. I believe that a layer in
GIS Manager is rather a slot for a Grass file than something which has
it's own identity.

> ***Pull-down menus:
> Keep menus as we have now for file, configuration, GIS function
> (raster, vector, 3D), database, extensions (I'm assuming that the
> GRASS Extension Manager will be default soon). Do we need a separate
> menu for help or can it go into configure or something like that?

I think a separate Help menu is a good idea. As it will have submenus
according to the Grass html help structure, it will be complex enough
to deserve a separate menu. 

>  Menus should call independent modules that can also be run from the
> command line. GRASS needs to remain scriptable for complex tasks and
> functions should be useable from command line for "power users".
> 
> RELATED UI ISSUES
> 
> ***Attribute data management:
> Now that GRASS has vectors with linked attribute data, there needs to
> be a reasonably decent UI for attribute data management and queries.
> Perhaps this could be developed along with the switch to a default
> attribute dbms based on SQLite.

I dream of a UI for attribute management, a kind of a spreadsheet with
elements of datable management. My wish list:

1. drop column
2. change column type:
I) to numeric:
	a) integer of a given value range
	b) floating of a given value range and number of decimal points
II) to text of a given number of characters
III) to date
3. search for string, value, column name; with support for wildcards and
regexp; find next,previous; in records search horizontaly,verticaly
4. mark records and columns with:
I) mouse, mouse+ALT for multiple separate
II) keyboard: 
	a) SHIFT+cursos keys
	b) SHIFT+pgup/pgdown
	c) SHIFT+CTRL+cursos keys for "jump to the next empty or end"
	d) SHIFT+end/home
	e) combination of the above with ALT for selecting multiple separate
III) mark records or colums based on search results; could be integrated
with search (3) as "find all"
6. filter colums and records in a column based on a given pattern
(wildcard and regexp)
7. drop table

> ***Printing:
> There should be integrated WYSIWYG printing to multiple devices from
> the GUI, including PDF files. ps.map functions should be integrated
> into GUI and be accessible without creating complex text file scripts.

Yup. But, if it is to be possible to prepare a decent map in the display
monitor and then export the monitor content directly into a
ps/pdf/printer, there is a bug to fix in display first:
http://intevation.de/rt/webrt?serial_num=3613&display=History.
Only for the record, if somebody capable of doing it is reading this by
any chance.

> ***Display output:
> Users should be able to save WYSIWYG display output to multiple
> graphic formats without scripting through a png driver or using
> gdal_translate. Formats supported should at least include tif, png,
> pnm, gif, jpg, svg, and xcf. 

So many formats? png for best compressed lossles indexed/RGB, jpg for
lossy and svg for vectors should do it. ps would do for hybrid. I guess
Grass team shouldn't mantain too much code in that regard, further image
processing should be up to the user. Xcf could make much sense on the
other hand, but only if layers where preserved, not as a one-layer image
dump. Is that what you mean in regard to xcf? That'd might be worthy of
the effort then I believe.

> ***Exiting:
> It should be possible to exit GRASS from the GUI rather than having to
> separately type "exit" on the command line.
Cool. 
> 
Some from me:

***MS*** Customization:
1. Font in different parts of the GUI. Font codepage.
2. Default monitor size and location on desktop. Different schemes for
different monitors could be handy to avoid overlapping.
3. Default main GUI location and dimensions.
4. Default location of terminals which pop up when queriying layers etc.
Their font size.
5. Database codepage.



--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/




More information about the grass-dev mailing list