WxPython-based GUI for GRASS: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
Line 531: Line 531:


'''Proposed solutions:'''
'''Proposed solutions:'''
* implement ''optional'' MDI (layout similar to QGIS or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' layout similar to QGIS (with a legend attached to each display) or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' magnetic docking of wxGUI windows to keep the windows closer
* implement ''optional'' magnetic docking of the layer manager and display windows to keep the windows closer
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)


Revision as of 19:53, 13 February 2010

See also GRASS GUI, GRASS and Python and GRASS SoC Ideas 2009‎.

For developer-related issues see Trac wxGUI page.

Overview

Requirements

Development

Do you want to help with the development?

  • basic Python programming ability required
  • GUI programming experience welcomed (especially wxPython)
  • GRASS user (or better developer) experience

How to get write access to the GRASS SVN repository.

Screenshots

GNU/Linux

Start-up screen
Vector digitizer
Attribute Table Manager
Querying vector map layers (attribute data)

Mac OS

MS Windows

Start-up screen
GUI dialog d.vect
Attribute Table Manager
Running command (r.buffer)
Querying vector map layer (editable mode)

 

Components

Layer Manager

Status: prototype implemented.

The GRASS GIS Layer Manager provides an interactive graphical interface to GRASS commands. The Layer Manager includes a set of pull-down menus for all GRASS GIS functions (analysis, file I/O, GIS configuration and management), toolbar that manage display map layers in map display windows, layer tree in which map layers to display are organized, command output window and integrated command line prompt.

Map display window

Status: prototype implemented.

Each Map display window has a unique set of layers to display and region setting (zoom). The map display window includes main toolbar with basic tools including zooming, panning, data querying, simple analyse functions (measure, profile, histogram, etc.), overlay management, etc. From main toolbar are accessible additional toolbars, currently only Digitization tool is available. Under development is Georectification tool.

Module GUIs

Status: prototype implemented.

Generated from XML using --interface-description.

E.g. d.rgb --help 

Description:
 Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
 display

Usage:
 d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
  -o   Overlay (non-null values only)
  -x   Don't add to list of commands in monitor
 --v   Verbose module output
 --q   Quiet module output

Parameters:
    red   Name of raster map to be used for <red>
  green   Name of raster map to be used for <green>
   blue   Name of raster map to be used for <blue>

becomes with d.rgb --interface-description 

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE task SYSTEM "grass-interface.dtd">
 <task name="d.rgb">
       <description>
               Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.
       </description>
       <keywords>
               display
       </keywords>
       <parameter name="red" type="string" required="yes" multiple="no">
               <description>
                       Name of raster map to be used for <red>
               </description>
               <keydesc>
                       <item order="1">name</item>
               </keydesc>
               <gisprompt age="old" element="cell" prompt="raster" />
       </parameter>
       <parameter name="green" type="string" required="yes" multiple="no">
               <description>
                       Name of raster map to be used for <green>
               </description>
               <keydesc>
                       <item order="1">name</item>
               </keydesc>
               <gisprompt age="old" element="cell" prompt="raster" />
       </parameter>
       <parameter name="blue" type="string" required="yes" multiple="no">
               <description>
                       Name of raster map to be used for <blue>
               </description>
               <keydesc>
                       <item order="1">name</item>
               </keydesc>
               <gisprompt age="old" element="cell" prompt="raster" />
       </parameter>
       <flag name="o">
               <description>
                       Overlay (non-null values only)
               </description>
       </flag>
       <flag name="x">
               <description>
                       Don't add to list of commands in monitor
               </description>
       </flag>
       <flag name="verbose">
               <description>
                       Verbose module output
               </description>
       </flag>
       <flag name="quiet">
               <description>
                       Quiet module output
               </description>
       </flag>
 </task>


which is then used to generate:

Startup GUI

Status: prototype implemented.

Start new GRASS session with 

grass -wxpython

Location wizard

Status: prototype implemented.

Wizard for creating new GRASS project location based on:

  • Coordinate system
  • EPSG code
  • Georeferenced file
  • PROJ.4 string
  • XY

See also GRASS Location Wizard.

Location wizard

Cartography tools

Status: development not started yet.

GUI for ps.map

  • ps.map 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 map canvas, 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
see also these discussions and pyGTK prototype by Jachym Cepicky
  • Start with most important mapping instructions
    • paper
    • scale
    • maploc
    • rast
    • vects
    • grids
    • scalebar
    • mapinfo
    • text labels
Intelligent label placement in ps.map
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.
Prototype g-ps.map

Direct printing

Implement direct printing of map canvas content using GRASS PS driver or Cairo driver.

Georectifier

Status: prototype implemented.

Profile Analysis Tool

Status: prototype implemented.

Vector digitizer

Status: prototype implemented.

Manual page.

See also GRASS Digitizing tool.

Replacement of v.digit module integrated to Map display window (Screenshots).

Vector digitizer (2008/04)
Vector digitizer (2007/11)
Vector digitizer - fill valid areas (closed boundary + centroid) (2008/07)
Vector digitizer - background raster maps with different opacity level (2008/07)

Raster digitizer

Status: development not started yet.

  • r.digit (merge with v.digit?)
Probably write a front end for r.in.poly, that's all the old r.digit is.
  • 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)
Category Labels
  • Write with new r.category import tool
    • Back-end component complete: r.category module is now updated to handle a rules= file and other goodies like dynamic labels
  • Read with one of r.category, r.describe, r.report, r.stats, ???
    • probably need to add a new flag to one of those to print flat "%d %s", cat, label
or read the cats/ file directly, it's already flat ascii.
  • how to deal with FP maps & cats?

Ortho photos

Status: development not started yet.

  • To replace i.ortho.photo and friends

Attribute table manager

Attribute Table Manager
Status: prototype implemented.

Manual page.


Allows
  • To browse attribute data, perform SQL select statements
  • Modify attribute data, insert new records to attribute table, delete existing records
  • Highlight selected items in Map Display Window
  • Extract selected items into new vector map layer
  • Modify attribute table - add, drop, rename columns
  • Modify vector map layer DB connestion settings - add, remove or modify layers

NVIZ replacement

Status: under development.

Detailed information wxNVIZ.

Imagery tools

Status: (re)development not started in earnest yet. Some behind-the-scenes code has been prepared, but not much.

Volunteers welcome!

Graphical modeller

Status: development not started yet.

GEM integration

Status: development not started yet.

GEM is GRASS Extension Manager. Or use the R packages approach.

Data Catalog

Status: Under development.
Data Catalog
Data Catalog


Current Features
  • copy, delete, rename map layers (raster & vector) in current mapset.
  • view raster & vector map layers from any location and any mapset.
  • Provides a GUI wrapper for r.info & v.info grass commands while viewing map layers in mapwindow.


To be implemented
  • copy, move map layers in different mapsets.
  • View DBF files as tables.
  • Copy, delete, rename DBF files.
  • Modify attribute tables.
  • Viewing other formats.
  • ...

Help browser

Status: development not started yet.

For browsing manual pages is currently used web browser, the goal is to design integrated help system.

HB: We used to have one of these for viewing the help pages of Tcl/Tk NVIZ. We dropped it because it was a pain to maintain and generally outside our core mission so a distraction.

Known issues

Platform specific

For the GUI to know what platform it's on, and therefore apply platform specific commands (e.g. append '.exe' to programs) it has to test what platform it is running on. Here we take the experimental approach to learning what's best to use. Please add or generalize this list as you can.

Platform information - start Python from the command line then issue 

 import sys
 sys.platform
 
 import os
 os.name
 os.environ['OS']
 
 import platform
 platform.system()
  • Results:
Platform sys.platform os.name os.environ['OS'] platform.system()
32bit GNU/Linux linux2 posix n/a Linux
64bit GNU/Linux linux2 posix n/a Linux
32bit Mac OSX (PowerPC G4) darwin posix n/a Darwin
64bit Mac OSX (Intel) [1] see note ? ? ?
32bit MS Windows XP win32 nt Windows_NT Windows
64bit MS Windows Vista win32 nt Windows_NT Windows
32bit MS Windows XP (Cygwin) win32 ? ? ?

[1] On Fri, May 29, 2009 at 10:49 PM, William Kyngesburye wrote:

Right now the GUI only runs 32bit, even if the rest of GRASS is 64bit, because it's not yet possible for wxPython to be 64bit. It comes out the same as PPC 32bit - no distinction between ppc/intel or 32/64 bit, it's all darwin. (yes, I checked, and I have a custom 64bit python executable to verify)

General GUI Design

Layout

For some users, the current approach of separate windows (SDI) leads to a windows flooding. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: example 1 and example 2. On a dual-screen this may sum up to 50cm of distance!

Proposed solutions:

  • implement optional layout similar to QGIS (with a legend attached to each display) or GSDView etc) (see figure below)
  • implement optional magnetic docking of the layer manager and display windows to keep the windows closer
  • If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)
Current wxGUI layout with detached window components
Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)

New solution: see data catalog above.


What others do:

See also

HowTo

Useful links

References

Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=WxPython-based_GUI_for_GRASS&oldid=10294"