GRASS GUI

wxPython GUI

General GUI Design

Move into Components section below

User's point of view

• GUI has multiple map displays
• Each map display has several buttons for basic functions
  • Zooming and Paning
  • Data Quering
• Each map display will be able to fire up pop-up toolbar with more complicated and not-so-often-used display functions (substitutions for d.measure, d.profile, d.text, ...)
• Each map display will be able to fire up pop-up toolbar with v.digit substitution
• Monitors can be started from the command line and from the GIS Manager
• Monitors must be able to display following types of layers
  • GRASS Raster
  • GRASS Vector
  • GDAL Raster
  • GDAL Vector
  • WMS Layer from remote server
  • WCS and WFS layers too
  • Text layers
  • Graphics layers
  • Grid
  • Image layers
  • ...
• GIS Manager is tool for
  • Monitors management and monitor content management
  • Layer look management
  • Modules starting (from integrated command line or menu)
  • Displaying output from modules (G_message, G_warning, G_fatal_error, G_percent)
• GIS Manager must be able to save and restore session
• There should be default session file, which will be loaded by default ones GRASS is started with -gui parameter
• Georectification tool should be part of new GUI. It should be special type of monitor with added GCP function
• Map Composer should be part of the new GUI. This tool should generate configuration files for hardcopy maps. The configuration files should be either ps.map files or maybe SVG

Coder's point of view

NOTE: As I have no coders background, sorry for inept formulated thoughts. --Jachym 09:13, 2 February 2007 (CET)

List of suggested classes and their purpose.

• Layer -- Raster, vector, WMS, whatever layer
  • Attributes -- Attributes are depending on layer type, but there are also common attributes marked with prefix "l_" (for 'layer'):
    • l_type -- vector, raster, wms, text, graph, ...
    • l_mapfile -- renderd ppm file
    • l_maskfile -- pgm file with layer's alpha channel
    • l_active -- layer is active, will be rendered only if True
    • l_hidden - layer is hidden, will be allways rendered
    • l_opacity - layer opacity [0-1]
  • Methods
    • Render -- runs d.* and similar commands for making content of l_mapfile

• Map -- Set of layers renderd to single PNG image, ready to display in Map display frame
  • Attributes
    • Width -- map width
    • Height -- map height
    • Region -- Region boundaries and resolution
    • Layers -- Array of Layers displayed in this "map"
    • MapFile -- path to resulting PNG file with rendered map
  • Methods
    • AddRasterLayer -- Adds GRASS-raster layer to list of layers
    • AddVectorLayer -- Adds GRASS-vector layer to list of layers
    • Add...Layer -- Adds some type of layer (wms, wfs, text, ...) to list of layers
    • GetListOfLayers -- Returns array of layers (active, hidden, type)
    • Render -- Creates final PNG image and stores it's path to MapFile

TSW Comment: perhaps it would be simpler to have AddLayer and pass the type as a parameter. Automatic would be nice, but since it is possible for vector and raster files to have the same name, this wouldn't work. Another option to consider would be to use AddLayer as a base class AddLayerRaster, ... as subclasses. This would make things more modular and theoretically at least, easier to maintain and develop.

JC Comment: I made separate functions for raster and vector, because of their attributes are completely different. There should be also AddWMSLayer etc. functions. IMHO it does not matter, if we have general AddLayer with parameter layer_type, or separate functions for all layer types.

• DigitToolbar -- Pop-up toolbar with digitising functions
• DisplayToolBar -- Pop-up toolbar with substitution of other d.* modules

• MapDisplay -- Frame (in wxWidgets terminology) with embed toolbar for zooming and paning and maybe data quering and pop-up toolbar for substitution of other d.* modules (d.path, d.profile, ...)

NOTE: This section should be completed

• • Attributes
    • Width
    • Height
    • Mouse -- mouse actions, movements, presed buttons etc.
    • Map -- Map class
  • Methods -- just very coarse definition
    • Zoom -- for zooming and paning
    • DrawBox -- For box drawing
    • DrawLine -- For line drawing
    • DrawPoint -- for points drawing

• GisManager -- GIS Manager frame
  • Attributes
    • Displays -- array with map displayes
  • Methods
    • AddDisplay -- Creates new map display
    • AddLayer -- Adds layer of defined type
    • EditLayer -- Opens pop-up window with layer attributes definition
    • ExecuteCommand -- Executes module from command line or menu

• GCPDisplay -- Special type of MapDisplay with tool for setting GCPs
• HCPDisplay -- Special type of MapDisplay with tools for creating configuration files for hardcopy maps

Used tools

wxPython seems to be the best tool for "new generation gui", because of it's multiplatformity and native look&feel on various platforms.

Where to get it

Jachym suggests to move the development to GRASS-Addons subversion repository, until it is "mature enough". Subversion enables for example to rename files, which could be useful. Current version can be found at https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_grassaddons_gui_ and downloaded with command

svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons grassaddons/gui

Write access to the GRASS-Addons SVN is managed by Markus Neteler.

Layout Concepts

Screenshots with proposed shapes

The wxGlade definition file is avaliable in the subversion repository	Another proposal by Michael Barton

Discussion / Comments

If the goal is to move toward a single command line interface integrated into the GUI, perhaps we should use the shape of a terminal window as the the shape of the new GIS manager. In this way the layers tree could appear next to the layer attributes in the same way the currently gis.m displays the layer attributes below the tree. The downside to this is having space on the desktop.

Another possibility would be to link the command window to the map display in the shape of an xterm, in this way the gis manager could have a profile shape by default that could easily fit onto a single screen for those without multiple display systems. Another possibility that might be desirable is to be able to 'tear off' the command window separately or link it to either the GIS manager tree or the display window.

It appears in the screen shots that multiple command windows are being considered (1 per map). In some ways this is potentially quite elegant especially if they are set up as separate sessions altogether so we wouldn't need to use win override. What we do encounter is issues related to multiple users which are non-trivial. Still as the layout suggest this it may be worth considering the impact of this, although the current solution in gis.m is probably the best for now.

GUI History

Link to wxPython prototype GUI for GRASS 6

Update 18:02, 14 August 2006 (CEST) New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!***** Cmbarton

Update 00:50, 9 August 2006 (CEST) New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. Cmbarton

Update 23:59, 7 August 2006 (CEST) New version with nearly complete raster menu by Yann Chemin. Cmbarton

Update 19:02, 7 August 2006 (CEST)I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:

• The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.

This can now be called from the command console (just type in the command name with no arguments as you do now) or the prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from other modules.

• Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac

--Cmbarton 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above. --Cmbarton 07:15, 4 August 2006 (CEST)

Components

Core GIS manager

• name? (does it even need one?)

Module GUIs

• Generate from XML --interface-description or new --wxpython switch?

Startup GUI

• for picking mapset etc

New location GUI

• Wizard for creating new location & region.

see QGIS's one

Cartography: GUI front end for ps.map

• This is a cartographic composer, intended to be a stand alone hardcopy plot generator. It is not meant to be a Print button for the maps currently displayed in the GIS manager, that will need it own controls.

• The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

• For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl

• Start with most important mapping instructions
  • paper
  • scale
  • maploc
  • rast
  • vects
  • grids
  • scalebar
  • mapinfo
  • text labels

Outputs

• ps.map instructions file
• PostScript file [ps.map instructions tmp file]
• lpr [PostScript tmp file]
• PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

Inputs

• Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

Georectifier

• Should be a simple port of Michael's tcltk Georectifier for gis.m

Digitizer

Vector

• Rewrite v.digit. Replace r.digit (r.in.poly format isn't far from v.in.ascii standard format)
• v.edit?
• Integrate d.rast.edit, d.rast.num functionality in another tool?
• We can use QGIS's digitizer in the interim.
• When to drop v.digit?

Raster

• r.digit (merge with v.digit?)
• d.rast.edit

Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

• merge with Georectifier? (i.points, i.vpoints)

Ortho photos

• To replace i.ortho.photo and friends

Tcl/Tk GUI

Screenshots: http://grass.itc.it/grass61/screenshots/index.php

Draft GUI design specifications

• See attached file

Summary of 2005 discussions on next generation UI for GRASS

• Attached file gives a distillation of several months of emails on the GRASS developers list. It includes a series of desired design features and specifications, along with supporting quotes.

Compiled emails from 2005 discussions on next generation UI for GRASS

• Attached file compiles all (or all that I could find) of the late 2005 emails on the GRASS developers list discussing proposed specifications for a next generation GRASS GUI. It is a series of rtm files that group the discussions according to a series of topics.