[GRASS5] Proposal for GRASS UI roadmap

[Michael Barton]

Maciek,

Thanks very much for the input. Your comments are just the type of thing we
need. Since this is just getting started, I want to respond to only
one--about the display windows. Here's my rationale. If any window could
have a 3D display, then you could achieve what you wanted by simply opening
a new display window with a copy of the current layer tree, and displaying
it in 3D mode. I'm worried a bit about screen clutter (one window for 2D
display and a separate one for 3D display of the same set of maps).

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Maciek Sieczka <werchowyna at epf.pl>
> Date: Sun, 06 Nov 2005 13:50:05 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: GRASS Developer's List <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Proposal for GRASS UI roadmap
> 
> 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/
>