Vaclav Petras | 16 Apr 04:30 2014

Who wants GUI and who does not and why

Hi all,

I believe, I was calling for this discussion recently, and I'm calling for it again. It seems that there are quite different opinions on GRASS GIS GUI ranging from "GUI is the only thing which brings us new users" to "no GUI needed".

There is no better time to discuss this: we are discussing issues with MS Windows support, planing to release 7, working towards compatibility of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently.

Here are recent quotations from "Handling of Python scripts on MS Windows" discussion ( with few notes and questions but feel free to start wherever you want.

On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <benducke <at>> wrote:
> On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <mlennert <at>> wrote:
> [Side note: The same discussion should also constantly be held about
> functionality which is specific to the GUI, because specifically
> developed for it), i.e. not just a GUI layer above command line
> functionality, something I'm afraid to see creep in more and more...]

Does this mean that you want remove everything from `gui/*` besides `gui/wxpython/forms/*`?
Agreed. Once more, I plead for a clean separation between GUI
and CLI developments, and a disconnection of their release cycles.

I see some advantages, for example just using same bug tracker makes difficult to say what is critical issue; but there are some GUI errors are tightly coupled to core module issues.

On the other hand, I don't see how these disconnected release cycles would work. Also it seems that it is impossible or very hard to create good GUI without the support of the processing and management tools.
The wxPython GUI can be considered a monolithic application,
and FWIW it can pull every trick in the book to integrate a
Python interpreter, and to make it all easier for Windows users.


I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
monolithic applications and let their maintainers figure out how
to deal with this. In the gvSIG CE project, we do a lot of hair-
raising stuff to hide the complexity of GRASS and its dependencies
from the end user, and I suspect so does QGIS. But I would not
advocate the same approach to the core GRASS architecture.

Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins. Managing one GUI less in OSGeo could save some work. For example, QGIS GRASS plugin is developed separately, so there is no need to have another graphical user interface for GRASS with disconnect development.

I also think that some of the debate comes from the question of whether
> the wxGUI should have a special status or whether it should just
> be treated as one of the hundreds of modules that GRASS offers.

This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui.

Or, are you satisfied with the situation as it is now?

Thanks for sharing your thoughts,
grass-dev mailing list
grass-dev <at>
Helmut Kudrnovsky | 12 Apr 20:29 2014

Tcl/Tk completly removed in grass trunk/relbranch7?


I've seen that in the preparing script for the standalone-installer
winGRASS7/relbranch7 these lines

	 <at> echo Copy Tcl/Tk content to PACKAGE_DIR\lib

is Tcl/Tk completly in grass trunk/relbranch7?

if yes, I will remove this leftover from the preparing script.


best regards
View this message in context:
Sent from the Grass - Dev mailing list archive at
Martin Landa | 11 Apr 10:38 2014

TOC in the manual

Hi all,

in r59673 I introduced simple mechanism to add TOC to the manual pages. It needs
some testing, anyway it seems to work. TOC is now fixed and width of
body part is 80%, see eg. [1]. Since wxPython widget doesn't support
most of css, it's shown before DESCRIPTION and not as fixed.




Martin Landa *
Markus Neteler | 10 Apr 15:33 2014

G7: r.neighbors changes data type from CELL to DCELL


in r59668 and r59669 I have fixed the issue that a map type
(CELL/FCELL/DCELL) was not preserved as expected but always converted

Now CELL is generated for

    {c_count, w_count, NO_CATS, 0, 0, 1, "count", "count of non-NULL values"},
    {c_divr, NULL, divr_cats, 0, 0, 1, "diversity",
    {c_intr, NULL, intr_cats, 0, 0, 1, "interspersion",

g.region rast=landuse96_28m -g landuse96_28m | grep datatype
r.neighbors input=landuse96_28m output=landuse96_28m_count7x7 method=count
 100% -g landuse96_28m_count7x7 | grep datatype

Remaining issues:

1) "quantile=0.5" creeps into the history: landuse96_28m_mode7x7
 |    r.neighbors input="landuse96_28m" output="landuse96_28m_mode7x7" met\   |
 |    hod="mode" size=3 quantile=0.5

--> quantile=0.5 should not be there (even if ignored).

2) The method=mode does not preserve CELL (likewise in r.series).

Any suggestion how to fix these two remaining problems?

Vaclav Petras | 10 Apr 03:51 2014

Structure of links for addons, manual pages etc.


I think we need to rethink the structure of addresses/links to various things which we are putting online.

The motivation are discussions "Linking Addons manual pages to core modules", "addons for windows", and "Addon manual pages not linked".

For example, so far we were linking the trunk documentation using grass70/manuals but since we forked the 70 branch these links now points to it and not to trunk. Also all general links to GRASS documentation leads to grass64/manuals but this will be soon very obsolete.

A lot of projects uses links such as latest, release or current (e.g. latest/manuals or release/manuals) which leads to the current (latest) release. And also links such as master, latest, trunk, nightly which leads to the one builds from the source code of the main branch. Alternatively, there is no special link for the current release which shortens URLs. I think something like this might be beneficial for us.

So far I identified this set of things:

* GRASS binaries
* addons for MS Windows
* addons SVN
* manual pages
* programming manual (or manuals)

I don't have any concrete suggestion now. What are your experiences with this?

grass-dev mailing list
grass-dev <at>
GRASS GIS | 9 Apr 13:13 2014

[GRASS GIS] #2252: wxGUI vector digitizer passing unescaped text to database

#2252: wxGUI vector digitizer passing unescaped text to database
 Reporter:  marisn       |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  blocker      |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
 It seems that it is not possible to enter attribute data for a new vector
 feature that is not valid SQL due to code being unable to pass user text
 to the database as text.

 Steps to reproduce:
  * Create a new vector data set;
  * Create a new text attribute column for it;
  * Digitize a new feature;
  * Provide following text as the attribute value: '; drop database
 important_data; '
  * Observe kaBOOM! as text is parsed by database instead of being properly
 escaped/passed as prepared statement to the DB.

 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near ";": syntax error

 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near ";": syntax error

 KĻŪDA: Error while executing: 'INSERT INTO remove_me (cat,nosaukums)
          VALUES (3,''; drop database important_data; '')'

 The issue will work also with more harmless examples like: It's fun

 For better effect enter value as: '); delete from MYVECTORMAP; select '


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
Markus Metz | 9 Apr 08:28 2014

relbr6 - devbr6 differences

Hi all,

I tried to synchronize the C code base of relbr6 and devbr6. I did not
port any new functionality to relb6 and did (hopefully) not change
translatable messages.

There are some outstanding issues:
- configure tests for X11/Xmu/Xmu.h in devbr6 (r53778) because it is
required by Nviz. This seems to be true also for relbr6. Backport?

- visualization/nviz backport?

- wxGUI backport?

- backport?

- d.grid/d.legend/ backport?

- the scripts differ substantially. Unfortunately, not many people are
testing the scripts in devbr6.

- there are differences in lib/pngdriver and lib/symbol that look like
backport candidates

- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.

- manuals TBD

Markus M
Anna Petrášová | 8 Apr 17:52 2014

addons for windows


there is now mess in URLs for downloading addon binaries for Windows. I fixed the url for releasebranch 7 (just hardcoded) but for example grass7 beta is not able to download addons. It would be nice to have the directory structure and version numbering synchronized so that the formatted url string could be the same for all branches. For example g.version says:

and the url:


grass-dev mailing list
grass-dev <at>
GRASS GIS | 8 Apr 16:34 2014

[GRASS GIS] #2251: highlight selected features and zoom - display not centered over the highlighted feature

#2251: highlight selected features and zoom - display not centered over the
highlighted feature
 Reporter:  madi                      |       Owner:  grass-dev <at> …              
     Type:  defect                    |      Status:  new                      
 Priority:  normal                    |   Milestone:  7.1.0                    
Component:  Vector                    |     Version:  svn-trunk                
 Keywords:  table, highlight, select  |    Platform:  All                      
      Cpu:  All                       |  
 When from attribute table manager you select a record then highlight
 selected features and zoom, the zoomed feature is not centered in the map
 display. Try for example on boundary_county vector map from nc dataset.
 Tested both on linux and windows.


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
GRASS GIS | 8 Apr 14:51 2014

[GRASS GIS] #2250: d.text unsupported from command line

#2250: d.text unsupported from command line
 Reporter:  veroandreo  |       Owner:  grass-dev <at> …              
     Type:  defect      |      Status:  new                      
 Priority:  normal      |   Milestone:  7.1.0                    
Component:  Display     |     Version:  unspecified              
 Keywords:  d.text      |    Platform:  Linux                    
      Cpu:  x86-64      |  

 d.text appears as an unsupported command in grass7 when
 used from command line. It does work when used from GUI, but for a loop
 it's really handy to have it running in the shell.

 GRASS 7.1.svn (plate_carree):~ > d.mon wx0[[BR]]
 GRASS 7.1.svn (plate_carree):~ > d.rast jan_average[[BR]]
 GRASS 7.1.svn (plate_carree):~ > d.text text="HOLA" at=30,30[[BR]]
 GRASS_INFO_WARNING(2716,1): Unsupported command d.text.[[BR]]

 GRASS 7.1.svn (plate_carree):~ > g.version -g[[BR]]



Ticket URL: <>

grass-dev mailing list
grass-dev <at>
Martin Landa | 8 Apr 14:03 2014

natural neighbor in G7?

Hi all,

potentially I have a student who could spend some time on this topic.
Currently we have for G6 an addons module (bash script) [1] which
depends on nn-c library [2]. This library is distributed under MIT
licence, but partly it's depending on tringle library [3] (Delaunay
triangulation) which is not really open source.

I see three possible options:

1) create new GRASS lib for nn from scratch (this is probably to much
for student work)
2) use open source lib which has nn implemented, eg. CGAL [4]. This
would require a new dependency for GRASS. CGAL is very powerful
library and could be probably used by other modules in the future.
3) use nn-c and replace triangle lib by open source solution (in GRASS
we have Delaunay triangulation so probably it could be reused?) nn-c
is distributed under MIT licence so it could be probably integrated to
the main code as an extenal library (lib/external) if I am right...

Any ideas? Thanks in advance, Martin



Martin Landa *