[[TOC]]

= Submitting wxGUI =

GUI is divided into components. One component is usually placed in one
directory.

Remember that functionality such as generating plots should be primarily
provided by library or modules not GUI.

Try to create create also `g.gui.*` module for the new GUI component. It helps
advanced users to access functionality and developers to test it. Moreover,
it helps to keep components separated and thus, it supports re-usability.

== File structure ==

Add a header section to each file you submit and make sure you
include the copyright. The purpose section is meant to contain a
general over view of the code in the file to assist other
programmers that will need to make changes to your code. For this
purpose use Python docstring.

The copyright protects your rights according to GNU General Public License (www.gnu.org).

Please use the following docstring template:

{{{
#!python
"""!
@package dir.example

@brief Short example package description

Classes:
 - example::ExampleClass

(C) 2012 by the GRASS Development Team

This program is free software under the GNU General Public License
(>=v2). Read the file COPYING that comes with GRASS for details.

@author First Author <first somewhere.com>
@author Second Author <second somewhere.com>
@author Some Other <third somewhere.com> (some particular change)
"""
}}}

== Documentation and comments ==

== Documentation and comments ==
Some information about docstrings:

 * always use """triple double quotes""" around docstrings
 * there's no blank line either before or after the docstring
 * add information on the parameters used by the function you have to use the following format 
   {{{
   :param TYPE NAMEPARAM: explanation
   }}}
   where TYPE is the type (bool, str, int) of parameter and it is optional; NAMEPARAM is the name of parameter
 * add information about the return of function using
   {{{
   :return: explanation
   }}}
 * add reference to classes and function using
   {{{
   :class:`CLASSNAME`
   :func:`FUNCNAME`
   }}}
 * add TODO in docstring as follow
   {{{
   .. todo::
       information todo
   }}}
   in similar way you can add warning and note.

When using class Signal from `grass.pydispatch.signal`, write a short description to as a constructor parameter and describe implementation details in standard comments
before the definition. Note the signal in each function which is invoking it.

== Writing the code ==

Do not use print command unless you know what you are doing.

Use `wx.ID_ANY` instead of `-1`.

Use `GError`, `GWarning` and `GMessage` instead of `wx.MessageBox()`

Do not use `grass.run_command()` or `grass.read_command()`.
Use functions and classes which use threads such as `RunCommand`.

When using `AddGrowableCol` and/or `AddGrowableRow` with sizers, put it after
adding widgets into the sizer, not just after creating of the sizer
(needed for wxPython >= 2.9).

== Testing ==

== See also ==

=== Related submitting rules ===

 * wiki:Submitting/General general GRASS and svn instructions
 * wiki:Submitting/Python Python library and scripts related instructions which applies to wxGUI too if not stated otherwise
 * wiki:Submitting/Docs user documentation of modules and GUI

=== GRASS GIS documentation ===

 * Sphinx Pages about how to develop wxGUI: http://grass.osgeo.org/grass71/manuals/wxgui/
 * Wiki Pages about how to develop wxGUI: http://grasswiki.osgeo.org/wiki/WxGUI
 * GRASS Trac wiki has pages about the state of wxGUI development: http://trac.osgeo.org/grass/wiki/wxGUIDevelopment
 * GRASS Programming manual for C API and existing classes: http://grass.osgeo.org/programming7/wxpythonlib.html
=== External documentation ===

 * wxPython Style Guide: http://wiki.wxpython.org/wxPython_Style_Guide