[GRASS-SVN] r61014 - grass/trunk
svn_grass at osgeo.org
svn_grass at osgeo.org
Fri Jun 27 08:08:33 PDT 2014
Author: martinl
Date: 2014-06-27 08:08:33 -0700 (Fri, 27 Jun 2014)
New Revision: 61014
Removed:
grass/trunk/SUBMITTING_DOCS
grass/trunk/SUBMITTING_PYTHON
grass/trunk/SUBMITTING_WXGUI
Modified:
grass/trunk/SUBMITTING
Log:
SUBMITTING files moved to Trac http://trac.osgeo.org/grass/wiki/Submitting
Modified: grass/trunk/SUBMITTING
===================================================================
--- grass/trunk/SUBMITTING 2014-06-27 15:06:31 UTC (rev 61013)
+++ grass/trunk/SUBMITTING 2014-06-27 15:08:33 UTC (rev 61014)
@@ -1,496 +1 @@
-NOTE: Please improve this list!
-
-Dear (new) GRASS developer,
-
-when submitting C code to GRASS SVN repository, please take care of
-following rules:
-
-[ see SUBMITTING_PYTHON for Python code hints ]
-[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
-[ see SUBMITTING_DOCS for documentation ]
-
-1. Get and read the GRASS Programmer's Manual here:
- http://grass.osgeo.org/programming7/
-
- or generate it from this source code (the programmer's manual is
- integrated in the source code in doxygen style):
- make htmldocs
- make pdfdocs
-
-
-2. Use the directory structure to place your module appropriately into
- the source tree
- - libes go into lib/
- - raster modules go into raster/
- - vector modules go into vector/
- - ...
-
- Consider to take a look at "GNU Coding Standards"
- http://www.gnu.org/prep/standards.html
-
-
-3. 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 overview of the code in the file to assist other
- programmers that will need to make changes to your code. If you
- are modifying an existing file you may under no circumstances
- remove prior copyright or licensing text that is not your own,
- even for a major rewrite. If any original code or code that is in
- part derived from another's original work remains, it must be
- properly cited.
-
- Example (ficticious header for a file called color.c) :
-
-/****************************************************************************
- *
- * MODULE: g.foo
- * AUTHOR(S): John Doe <jdoe at somewhere org>
- * PURPOSE: Provide short description of module here...
- * COPYRIGHT: (C) 2010 by John Doe, and the GRASS Development Team
- *
- * This program is free software under the GNU General Public
- * License (>=v2). Read the COPYING file that comes with GRASS
- * for details.
- *
- *****************************************************************************/
-
- The copyright protects your rights according to GNU General Public
- License (www.gnu.org).
-
-
-4. We don't want the $ID$ in source code any more as it causes problems
- for the SVN branches.
-
-
-5. To ensure that the software system continues to work, please include
-
- #include <grass/config.h>
-
- in your files and make use of the various system dependencies
- contained therein. As one example of this, see lib/gmath/fft.c.
- Please refrain from declaring system functions within the
- software; include the proper header files (conditionally dependent
- on config.h macros if necessary) instead.
-
-
-6. Order of include headers
-
- In general, headers should be included in the order:
-
- 1. Core system headers (stdio.h, ctype.h, ...)
- 2. Headers for non-core system components (X11, libraries).
- 3. Headers for core systems of the package being compiled (grass/gis.h, grass/glocale.h, ...)
- 4. Headers for the specific library/program being compiled (geodesic.h, ...)
-
- Each class of header has an obligation to be compatible with those
- above it in the list, but not those below it.
-
-
-7. Always specify the return type for ALL functions including those that
- return type "void", and insert return statements for any function
- which returns a value.
-
- Also, use ANSI C prototypes to declare your functions.
- For module return values, see "Exit status" below.
-
- Examples:
-
- void G_something(void);
- int G_something_else(int, int);
-
- void G_something(void)
- {
- /* Snipped out code */
-
- return;
- }
-
- int G_something_else(int x, int y)
- {
- /* Snipped out code */
-
- return 0;
- }
-
-
-8. Module exit status is defined as EXIT_SUCCESS or EXIT_FAILURE
- (declared in stdlib.h), e.g.
-
- {
- ...
- if (G_parser (argc, argv))
- exit (EXIT_FAILURE);
-
- ...
- exit (EXIT_SUCCESS);
- }
-
-
-9. Use fprintf() instead of printf()
-
- For errors and warnings please use the G_fatal_error() and
- G_warning() functions. General messages for the user should use
- G_message() while debug messages should use G_debug() whenever
- possible. There are two variants to G_message(): G_verbose_message()
- which will only display the message if in --verbose mode, and
- G_important_message() which will always show the message unless
- the module is running in --quiet mode. G_fatal_error() and
- G_warning() will always be displayed regardless of verbosity setting.
- Messages sent to any of these functions will be printed to stderr.
-
- G_message() output is not expected to be sent to pipe or file.
-
- Always use the gettext macros with _("") for user messages,
- example:
- G_fatal_error(_("Vector map <%s> not found"), name);
- It is suggested to add a comment line before translatable user message
- to give a hint to translators about meaning or use of
- cumbersome or obscure message. First word in the comment must be GTC
- - GRASS translation comment,
- example:
- /* GTC A name of a projection */
- G_message(_("State Plane"));
-
- Any message with a noun in plural form has to pass _n() macro,
- even if for the English language it is not required!
- G_message(_n("One map", "%d maps", number), number);
-
- See locale/README for details.
-
-
- Pipe/file data output:
- For data output redirected to pipe or file, please use fprintf() and
- specify the stdout stream as follows:
-
- fprintf(stdout, ...);
- fflush(stdout);
-
- fflush(stdout) always required when using fprintf(stdout, ...).
-
-
-10. Use the GRASS library function G_asprintf() instead of the
- standard C functions asprintf(), vsnprintf() and snprintf(). These
- functions are not portable or have other issues. Example:
-
- char *msg;
-
- G_asprintf(&msg, "%s", parameters);
- do_something_with_msg();
- G_free(msg);
-
- Note that you should free memory when G_asprintf() is used.
-
-
-11. Use the following GRASS library functions instead of the standard C
- functions. The reason for this is that the following functions ensure
- good programming practice (e.g. always checking if memory was allocated)
- and/or improves portability. PLEASE refer to the programmers manual
- for the proper use (e.g. determining if any casts are needed for arguments
- or return values) of these library functions. They may perform a task
- slightly different from their corresponding C library function, and thus,
- their use may not be the same.
-
- G_malloc() instead of malloc()
- G_calloc() instead of calloc()
- G_realloc() instead of realloc()
- G_free() instead of free()
- G_getenv() instead of getenv()
- G_setenv() instead of setenv()
- G_unsetenv() instead of unsetenv()
- G_sleep() instead of sleep()
-
- Could somebody please add others (please verify that they are
- useful and safe first)
-
-
-12. Use function names which fulfill the official GNU naming convention.
- http://www.gnu.org/prep/standards/html_node/Names.html#Names
-
- Instead of naming a function like: MyNewFunction() use underscores
- for seperation and lower case letters: my_new_function().
-
-
-13. Don't use the C++ comment style! This confuses several compilers.
- Use instead:
- /* C-comments */
-
- If you want to comment code portions, use
- #ifdef notdef
- portion_to_be_commented;
- #endif
- This is safe comparing to nested /* comments */
-
- Functions in the library must be documented in doxygen style to
- get them into the programmer's manual (generate with
- make pdfdocs or
- make htmldocs
- ). See lib/gis/*.c for examples.
-
-
-14. PLEASE take the time to add comments throughout your code explaining what
- the code is doing. It will save a HUGE amount of time and frustration for
- other programmers that may have to change your code in the future.
-
-
-15. To promote a consistent coding style, please use the "indent" program
- on all new C modules using the following switches:
-
- $ indent -bad -bap -bbb -br -bli0 -bls -cli0 -ncs -fc1 -hnl -i4 \
- -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
- -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut main.c
-
- Existing code should not be re-indented except in extreme cases, as this
- will make "diff" comparisons with older versions impossible. If indent is
- needed, do not check in any changes other than the indentation in the same
- commit! Do add the indent switches and any indent warning messages to the
- SVN log. Any change or fix mixed in with an indent is very hard to track
- making it hard for others to follow the change or fix any new bugs.
- For your convenience use the tools/grass_indent.sh script.
-
-
-16. Platform dependent code:
- Do not remove #ifdef __CYGWIN__ and/or #ifndef __CYGWIN__ lines and
- their encapsulated lines from source code (one example was that someone
- removed drand48 definition.)
-
-
-17. Suggested compiler flags:
- We suggest to use very strict compiler flags to capture errors
- at the very beginning. Here our list of flags, please use them
- to configure you development version of GRASS:
-
- GNU/Linux:
-
- MYCFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common"
- MYCXXFLAGS="-g -Wall"
-
- CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS" ./configure ...
-
- MacOSX: [to be suggested]
-
- MS-Windows: [to be suggested]
-
-
-18. Make sure a new line is at the end of each file and UNIX style newlines
- are used (\n).
-
-
-19. When writing Makefiles, use the current standard.
-
- If you have to use commands, please check for:
-
- avoid | use instead
- ------------------+---------------
- make target | $(MAKE) target
- mkdir target | $(MKDIR) target
- cp (executable) | $(INSTALL) -m 755 file target
- cp (normal file) | $(INSTALL) -m 644 file target
- ar | $(AR)
-
- rm: be VERY careful with recursive remove. Also beware of
- removing $(FOO)* if $(FOO) has any chance of being empty.
-
- Examples: see below examples or others
- raster/r.info/Makefile
- vector/v.edit/Makefile
-
- If you are unsure, please ask on the GRASS Developers list.
-
-
-20. Have a look at ./INSTALL
-
-
-21. Have a function included in your module which writes to the history
- file of the map (e.g. command line, parameters etc.). See e.g.
- raster/r.patch/main.c
-
- (the same applies to vector and g3d modules!)
-
-
-22. Standard parser options: use G_define_standard_option() whenever possible
- to define standard module command line options. This will save you time,
- create fewer bugs, and make things easier on the translators.
- See lib/gis/parser.c for details of the function definition.
-
-
-23. Add/update, if required the related GUI menus:
- gui/wxpython/xml/menudata.xml
-
-
-24. For consistency, use README rather than README.txt for any README files.
-
-
-25. GRASS/Environment variables:
- If you add a new variable, please follow the naming convention.
- All variables are described in
- lib/init/variables.html
-
-
-26. Be sure to develop on top of the LATEST GRASS code (which is in our SVN
- repository). You can re-check before submission with 'svn diff':
-
- Be sure to create unified ("diff -u") format. "Plain" diffs (the default
- format) are risky, because they will apply without warning to code which
- has been substantially changed; they are also harder to read than unified.
-
- Such diffs should be made from the top-level directory, e.g.
- "svn diff display/d.vect/main.c"; that way, the diff will
- include the pathname rather than just an ambiguous "main.c".
-
-
-27. Try to use module names which describe shortly the intended purpose of the module.
-
- The first letters for module name should be:
- d. - display commands
- db. - database commands
- g. - general GIS management commands
- i. - imagery commands
- m. - miscellaneous tool commands
- ps. - postscript commands
- r. - raster commands
- r3. - raster3D commands
- v. - vector commands
-
- Some additional naming conventions
- * export modules: (type).out.(format) eg: r.out.arc, v.out.ascii
- * import module: (type).in.(format) eg: r.in.arc, v.in.ascii
- * conversion modules: (type).to.(type) eg: r.to.vect, v.to.rast, r3.to.rast
-
- Avoid module names with more than two dots in the name.
- Example:
- instead of r.to.rast3.elev use r.to.rast3elev
-
-
-28. Use the grass test suite to test your modules.
-
- http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite
-
- You can easily write specific tests for your modules.
-
- If your module is part of GRASS and you created some standard test
- cases, please contact the developers to add your tests to the
- default test suite. This will automatize complex test scenarios
- and assure to find bugs much faster, if changes were made to your
- modules or to the grass library.
-
- Consider to subscribe to the GRASS Quality Assessment System to
- get immediate notification about the code quality:
-
- http://lists.osgeo.org/mailman/listinfo/grass-qa
-
-
-29. When submitting new files to the repository set SVN properties,
- usually for directory
-
- svn:ignore : *.tmp.html
- *OBJ*
-
- or e.g. for C-file
-
- svn:mime-type : text/x-csrc
- svn:keywords : Author Date Id
- svn:eol-style : native
-
- See
- http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
-
- To set a property:
-
- svn propset svn:keywords 'Author Date Id' <file>
- svn propset svn:mime-type text/x-sh grass_shellscript.sh
-
- To edit the svn:ignore property using your default text editor:
-
- svn propedit svn:ignore <directory>
-
- To set the svn:ignore property non-interactively, first create a
- file containing the value:
-
- echo "*.tmp.html" > ignore.txt
- echo "*OBJ*" >> ignore.txt
-
- then use:
-
- svn propset -F ignore.txt svn:ignore <directory>
-
- List of mime-type:
- C++ files (.cpp): text/x-c++src
- C files (.c): text/x-csrc
- DTD files (.dtd): text/xml-dtd
- GIF files (.gif): image/gif
- Header files (.h): text/x-chdr
- HTML files (.html): text/html
- JPEG files (.jpg): image/jpeg
- Makefiles: text/x-makefile
- PNG files (.png): image/png
- Python files (.py): text/x-python
- Shell scripts (.sh): text/x-sh
- Text files (.txt): text/plain
- XML files (.xml): text/xml
-
- (please update the list...)
-
- For your convenience use the tools/module_svn_propset.sh script.
-
-30. Use doxygen style for source code documentation. It is required
- for GRASS libraries, but also recommended for GRASS modules.
-
- Do not use structural command inside documentation block since it
- leads to some duplication of information (e.g. do not use \fn
- command in comment blocks). The exception is \file command for
- documenting a file, in this case structural command is required.
-
- For files
-
- /*!
- \file snap.c
-
- \brief Vector library - Clean vector map (snap lines)
-
- (C) 2001-2008 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 Radim Blazek
- */
-
- For functions
-
- /*!
- \brief Snap lines in vector map to existing vertex in threshold
-
- For details see Vect_snap_lines_list()
-
- \param Map pointer to input vector map
- \param type filter features of given type to be snap
- \param thresh threshold value for snapping
- \param[out] Err pointer to vector map where lines representing snap are written or NULL
- \param[out] msgout file pointer where messages will be written or NULL
-
- \return 1
- */
-
-
-31. If you need to add support for a different library in the 'configure' script,
- you should first seek consent in the grass-dev mailing list (see below), then
- you need to expand 'configure.in' and run subsequently autoconf-2.13 (later
- versions will not work) to re-generate 'configure'.
-
-32. Tell the other developers about the new code using the following e-mail:
- grass-dev at lists.osgeo.org
-
- To subscribe to this mailing list, see
- http://lists.osgeo.org/mailman/listinfo/grass-dev
-
-
-33. In case of questions feel free to contact the developers at the above
- mailing list.
- http://grass.osgeo.org/development/
-
-...
-[please add further hints if required]
-
-
-"Your attention to detail is appreciated."
+See http://trac.osgeo.org/grass/wiki/Submitting
Deleted: grass/trunk/SUBMITTING_DOCS
===================================================================
--- grass/trunk/SUBMITTING_DOCS 2014-06-27 15:06:31 UTC (rev 61013)
+++ grass/trunk/SUBMITTING_DOCS 2014-06-27 15:08:33 UTC (rev 61014)
@@ -1,124 +0,0 @@
-NOTE: Please improve this list!
-
-Dear (new) GRASS GIS Developer,
-
-When submitting documentation to GRASS SVN repository, please take
-care of following rules:
-
-[ see SUBMITTING for C hints ]
-[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
-[ see SUBMITTING_PYTHON for Python code hints ]
-
-
-0. Introduction
-
- There are two types of documentation
- - Libraries programmers docs: we use doxygen and document the functions
- directly in the source code. See lib/gis/*.c and lib/gis/gislib.dox for examples
-
- - User manual: we write it in simple HTML, storing the manual in a
- file '<module>.html' within the subdirectory of the module.
- The file contains no header nor footer. The complete HTML file is
- autogenerated during the compilation process (indeed, it is generated
- in a virtual session directly after compilation of the module).
- In this virtual session the module is called internally with
- --html-description which generates the parameters/flags list in
- HTML format, along with '<module>.html', HTML header and footer
- the final HTML manual page is created and stored in the target
- binaries directory. In a separate process the MAN format is
- generated from the complete HTML files.
-
-1. Editing of HTML pages
- To avoid insertion of too complicated HTML tags (see also below),
- we strongly suggest to use a plain text editor rather than a
- HTML editor for editing.
-
-
-2. Module manual page:
- Place the documentation in HTML format into '<module>.html', where
- <module> is the name of the module. E.g. if the module is named
- r.example, the documentation file should be named r.example.html.
-
- The easiest way to do this is to study an existing HTML page
- (to get the page style, e.g. vector/v.to.db/v.to.db.html).
- With a few exceptions, header and footer are NOT allowed.
- You can add figures (PNG format); the figure name prefix should be the
- module name. See raster/r.terraflow/r.terraflow.html for an example.
-
- A number of major sections should be present in each help page.
-
- * = Required
- ! = Suggested
- . = Optional
-
- In recommended order
- --------------------
-
- * <h2>DESCRIPTION</h2>
- ! <h2>NOTE</H2>, <h2>NOTES</h2>
- ! <h2>EXAMPLE</h2>, <h2>EXAMPLES</h2>
- . <h2>TODO</h2>
- . <h2>BUGS</h2>
- . <h2>REFERENCE</h2>, <h2>REFERENCES</h2>
- * <h2>SEE ALSO</h2>
- * <h2>AUTHOR</h2>, <h2>AUTHORS</h2>
-
- Note that the parameter information is auto-generated upon
- compilation. This is done by running the module in a virtual session
- after compilation (see the output of 'make'). To subsequently
- verify the final HTML page, check the resulting HTML pages which
- will be stored with the name of the module.
-
- Examples (please add some) should be coded like this:
-
- <div class="code"><pre>
- v.to.db map=soils type=area option=area column=area_size unit=h
- </pre></div>
-
- The online WWW man pages is updated every Saturday (from SVN
- repository).
-
-
-3. Usage of limited HTML tags
- Since the MAN conversion of g.html2man is limited, please use
- no other HTML tags than:
- <a> <b> <body> <br> <code> <dd> <dl> <dt> <em>
- <h2> <h3> <h4> <head> <hr> <i> <img> <li> <ol> <p>
- <pre> <sup> <table> <td> <th> <title> <tr> <ul>
-
- Note that all tags has a closing tag except for <hr/>, <br/> and <p>.
- Use lower case forms.
-
- (The MAN converter is here: tools/g.html2man/)
-
-4. Suggested HTML markup protocol:
- Module names (i.e., v.category) should be emphsized with <em>,
- and boldface <b> for flags and parameter names. Shell commands,
- names, values, etc. should use <tt>. Empahsized phrases should use
- italics <i>. The SEE ALSO section of each page should also be
- alphabetized.
-
-
-5. When submitting new files to the repository set SVN properties,
- e.g. for HTML file
-
- svn:mime-type : text/html
- svn:keywords : Author Date Id
- svn:eol-style : native
-
- See
- http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
-
- You can also simply use this script:
- http://svn.osgeo.org/grass/grass-addons/tools/module_svn_propset.sh
-
-6. Compress PNG images with
- optipng -o5 file.png
-
-7. See also
- http://grass.osgeo.org/wiki/Updating_GRASS_Documentation
-
-...
-[please add further hints if required]
-
-"Your attention to detail is appreciated."
Deleted: grass/trunk/SUBMITTING_PYTHON
===================================================================
--- grass/trunk/SUBMITTING_PYTHON 2014-06-27 15:06:31 UTC (rev 61013)
+++ grass/trunk/SUBMITTING_PYTHON 2014-06-27 15:08:33 UTC (rev 61014)
@@ -1,180 +0,0 @@
-NOTE: Please improve this list!
-
-Dear (new) GRASS developer,
-
-when submitting Python code to GRASS SVN repository, please take
-care of following rules:
-
-[ see SUBMITTING for C hints ]
-[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
-[ see SUBMITTING_DOCS for documentation ]
-
-See also http://www.python.org/dev/peps/pep-0008/
-
-0. Indentation
-
- As Python determines nesting based upon indentation, it isn't just
- a stylistic issue.
-
- Please use 4-space indentation (GNU Emacs python-mode default).
-
- See also "Python Style Guide" by Guido van Rossum
- http://www.python.org/doc/essays/styleguide.html
-
-
-1. Instructions for the GRASS script parser can be found in the g.parser
- module's help page.
- http://grass.osgeo.org/grass70/manuals/g.parser.html
-
-
-2. Use the directory structure to place your script appropriately into
- the source tree
- - scripts go into scripts/
-
- Also add a Makefile and a <module>.html file into this directory.
- See existing Python scripts for examples.
-
-
-3. Add a header section to the script 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, see
- http://epydoc.sourceforge.net/docstrings.html
-
- Example (fictitious header for a script called g.myscript):
-
-"""
-MODULE: g.myscript
-
-AUTHOR(S): John Doe <email AT some domain>
-
-PURPOSE: Describe your script here...
-
-COPYRIGHT: (C) 2007 John Doe, and 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.
-"""
-
- The copyright protects your rights according to GNU General Public
- License (www.gnu.org).
-
- You can easily autogenerate the header and parameters from an existing
- module using the --script flag. Example:
-
- d.rast --script
-
- Just select an existing module which is close to your application to save
- efforts.
-
-
-4. We don't want the $ ID $ in source code any more as it causes problems
- for the branches.
-
-
-5. Create and use secure temporary files and directories. Use the
- grass.tempfile() or grass.tempdir() functions to do this. e.g.
-
- # setup temporary file
- TMP = grass.tempfile()
- if TMP is None:
- grass.fatal("Unable to create temporary files")
-
-
-6. Use grass.findfile() when there is a need to test if a map exists.
-
- # test for input raster map
- result = grass.find_file(name = map_name, element = 'cell', quiet = True)
- if not result['file']
- grass.fatal("Raster map <%s> not found" % map_name)
-
- # test for input vector map
- result = grass.find_file(name = map_name, element = 'vector', quiet = True)
- if not result['file']
- grass.fatal("Vector map <%s> not found" % map_name)
-
- ... and so forth. See 'g.manual g.findfile' for details.
-
-7. For any informational output, use the grass.message()
- function. For error messages should be used grass.fatal_error() or
- grass.error() and for warnings grass.warning(). For debugging
- purposes grass.debug().
-
- #normal message:
- grass.message("Done")
-
- # warning:
- grass.warning("No input values found, using default values")
-
- # error:
- grass.error("No map found")
-
- # fatal error:
- grass.fatal_error("No map found, exiting")
-
- # debug output (use g.gisenv to enable/disable)
- grass.debug("Our calculated value is: %d" % value)
-
- Try to omit any usage of the 'print' command for informational output.
-
-
-8. PLEASE take the time to add comments throughout your code explaining what
- the code is doing. It will save a HUGE amount of time and frustration for
- other programmers that may have to change your code in the future.
-
-
-9. Make sure a new line is at the end of each file.
-
-
-10. For consistency, use README rather than README.txt for any README files.
-
-
-11. Be sure to develop on top of the LATEST GRASS code (which is in SVN repository).
- You can re-check before submission with 'svn diff':
-
- Be sure to create unified ("diff -u") format. "Plain" diffs (the default
- format) are risky, because they will apply without warning to code which
- has been substantially changed; they are also harder to read than unified.
-
- Such diffs should be made from the top-level directory, e.g.
- "svn diff gui/wxpython/wxgui.py"; that way, the diff will
- include the pathname rather than just "wxgui.py".
-
-
-12. When submitting new files to the repository set SVN properties,
- usually for directory
-
- svn:ignore : *.pyc
-
- or e.g. for Python file
-
- svn:mime-type : text/python
- svn:keywords : Author Date Id
- svn:eol-style : native
-
- svn propset svn:mime-type text/python new/file.py
- svn propset svn:keywords "Author Date Id" new/file.py
- svn propset svn:eol-style native new/file.py
-
- See
- http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
-
-
-13. Tell the other developers about the new code using the following e-mail:
- grass-dev at lists.osgeo.org
-
- To subscribe to this mailing list, see
- http://lists.osgeo.org/mailman/listinfo/grass-dev
-
-
-14. In case of questions feel free to contact the developers at the above
- mailing list.
- http://grass.osgeo.org/development/
-
-...
-[please add further hints if required]
-
-
-"Your attention to detail is appreciated."
Deleted: grass/trunk/SUBMITTING_WXGUI
===================================================================
--- grass/trunk/SUBMITTING_WXGUI 2014-06-27 15:06:31 UTC (rev 61013)
+++ grass/trunk/SUBMITTING_WXGUI 2014-06-27 15:08:33 UTC (rev 61014)
@@ -1,160 +0,0 @@
-NOTE: Please improve this list!
-
-Dear (new) GRASS developer,
-
-when submitting Python code to GRASS SVN repository, please take
-care of following rules:
-
-[ see SUBMITTING for C hints ]
-[ see SUBMITTING_PYTHON for Python code hints ]
-[ see SUBMITTING_DOCS for documentation ]
-
-
-0. Introduction
-
- For general GRASS, svn and Python issues and module related issues see
- SUBMITTING_PYTHON and SUBMITTING.
-
- GUI is divided into components. One component is usually placed in one
- directory.
-
-
-1. GRASS documentation
-
- GRASS Programming manual for API and existing classes
- http://grass.osgeo.org/programming7/wxpythonlib.html
-
- GRASS wiki has pages about how to develop wxGUI
- http://grasswiki.osgeo.org
-
- GRASS Trac wiki has pages about the state of wxGUI development
- http://trac.osgeo.org/grass/wiki/wxGUIDevelopment
-
-
-2. External documentation
-
- Style Guide for Python Code
- http://www.python.org/dev/peps/pep-0008/
-
- Python Style Guide by Guido van Rossum
- http://www.python.org/doc/essays/styleguide.html
-
- wxPython Style Guide
- http://wiki.wxpython.org/wxPython_Style_Guide
-
- Additional info on Python docstrings
- http://epydoc.sourceforge.net/docstrings.html
-
-
-3. Remember that functionality such as generating plots should be primarily
- provided by modules not GUI.
-
-
-4. 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, supports re-usability.
-
-
-5. 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:
-
- """!
- @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)
- """
-
-
-6. Comment your classes and functions with docstrings. Use Doxygen syntax,
- particularly, use commands which begins with @
- (www.doxygen.org/manual/commands.html).
-
- Comment also the code itself such as the meaning of variables,
- conditions etc.
-
-
-7. Make sure a new line is at the end of each file. Non empty line breaks the
- build process.
-
-
-8. Basic rules
-
- Do not use print command unless you know what are you doing.
-
- Use named parameters in functions (without space around '='), e.g.
-
- dlg = wx.FileDialog(parent=self, message=_("Choose file to save current workspace"),
- wildcard=_("GRASS Workspace File (*.gxw)|*.gxw"), style=wx.FD_SAVE)
-
- instead of
-
- dlg = wx.FileDialog(self, _("Choose file to save current workspace"),
- _("GRASS Workspace File (*.gxw)|*.gxw"), wx.FD_SAVE)
-
- 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 uses threads such as RunCommand.
-
- Use full strings, e.g.
-
- if ...:
- win.SetLabel(_('Name for new 3D raster map to create'))
- else:
- win.SetLabel(_('Name for new raster map to create'))
-
- instead of
-
- _('Name for new %s to create') % maplabel
-
- where `maplabel` can be 'raster map' or '3D raster map'
-
- When using AddGrowableCol/AddGrowableRow with sizers, put it after
- adding widgets into the sizer, not just after creating of the sizer
- (needed for wxPython >= 2.9).
-
-
-9. Use tools such as pylint and pep8 to check your code (both style and
- correctness). Just note that default settings of these tools is not fully
- compatible with wxGUI/wxPython style and that some of the reported errors
- may not apply to your code.
-
-
-14. Tell the other developers about the new code using the following e-mail:
- grass-dev at lists.osgeo.org
-
- To subscribe to this mailing list, see
- http://lists.osgeo.org/mailman/listinfo/grass-dev
-
-
-15. In case of questions feel free to contact the other developers at the above
- mailing list.
- http://grass.osgeo.org/development/
-
-
-[please add further hints if required]
-
-
-"Your attention to detail is appreciated."
More information about the grass-commit
mailing list