[GRASS-SVN] r62097 - in grass/trunk: . gui/wxpython include/Make lib/python/ctypes lib/python/imaging lib/python/pydispatch lib/python/pygrass lib/python/script lib/python/temporal

svn_grass at osgeo.org svn_grass at osgeo.org
Fri Sep 26 11:57:08 PDT 2014


Author: martinl
Date: 2014-09-26 11:57:08 -0700 (Fri, 26 Sep 2014)
New Revision: 62097

Removed:
   grass/trunk/gui/wxpython/wxguitoolboxes.dox
   grass/trunk/gui/wxpython/wxpythonlib.dox
   grass/trunk/lib/python/imaging/imaginglib.dox
   grass/trunk/lib/python/pydispatch/pydispatchlib.dox
   grass/trunk/lib/python/pygrass/pygrasslib.dox
   grass/trunk/lib/python/script/pythonlib.dox
   grass/trunk/lib/python/temporal/pythontemporallib.dox
Modified:
   grass/trunk/grasslib.dox
   grass/trunk/gui/wxpython/Makefile
   grass/trunk/include/Make/Docs.make
   grass/trunk/include/Make/Doxyfile_arch_html.in
   grass/trunk/include/Make/Doxyfile_arch_latex.in
   grass/trunk/lib/python/ctypes/Makefile
   grass/trunk/lib/python/imaging/Makefile
   grass/trunk/lib/python/pydispatch/Makefile
   grass/trunk/lib/python/pygrass/Makefile
   grass/trunk/lib/python/script/Makefile
   grass/trunk/lib/python/temporal/Makefile
Log:
doxygen: remove python documentation (replaced by sphinx)


Modified: grass/trunk/grasslib.dox
===================================================================
--- grass/trunk/grasslib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/grasslib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -53,11 +53,6 @@
  - vector: \ref vectorlib
  - Temporal GIS API: \ref pythontemporallib
 
-\section interfaces Interfaces
-
- - Python script interface: \ref pythonlib
- - %PyGRASS: A Python based object oriented raster, vector library interface
-
 \section libs Further libraries
 
 (the name refers to the directory name in <tt>lib/</tt> in the source code)
@@ -126,10 +121,6 @@
  - manage:      \ref managelib
  - symbol:	\ref symbol (Drawing symbols for %point %vector data library)
 
-\section gui GUI
-
- - \ref wxpythonlib
-
 \section location File structure of GRASS Location
 
 A GRASS <b>raster map</b> consists of several files in several subdirectories in a mapset,

Modified: grass/trunk/gui/wxpython/Makefile
===================================================================
--- grass/trunk/gui/wxpython/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/gui/wxpython/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -4,7 +4,6 @@
 EXTRA_CLEAN_FILES = menustrings.py build_ext.pyc xml/menudata.xml xml/module_tree_menudata.xml
 
 include $(MODULE_TOPDIR)/include/Make/Dir.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
 
 DSTDIR = $(GUIDIR)/wxpython
@@ -62,6 +61,3 @@
 
 $(DSTDIR):
 	$(MKDIR) $@
-
-#doxygen:
-DOXNAME = wxpython

Deleted: grass/trunk/gui/wxpython/wxguitoolboxes.dox
===================================================================
--- grass/trunk/gui/wxpython/wxguitoolboxes.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/gui/wxpython/wxguitoolboxes.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,377 +0,0 @@
-/*! \page wxguitoolboxes WxGUI Toolboxes
-
-\tableofcontents
-
-\section introduction Introduction
-
-wxGUI toolboxes enables GUI customization and organization of menu (and other
-views) according to user needs.
-
-XML files are used for code generation and in case of toolboxes enables
-wxGUI (menu) customization.
-
-Currently, all the files described here are related to the menus which are
-generated from these files. The most of the files described here are
-the part of implementation of toolboxes in wxGUI.
-
-Each XML file has a DTD file which can by used for validation. XSD files are
-not provided (but this can change in the future). Some file types can occur
-multiple times, some occur only once.
-
-Note that in XML context, the term <i>tag</i> partially overlaps with the term
-<i>element</i>. Element emphasizes the XML structure, XML object model and
-content of these objects. Tag emphasizes the markup and the name of the element.
-
-
-\section toolboxesFilesOverview Files overview
-
-\subsection toolboxesFiles Files related to toolboxes
-
-GRASS source code contains these XML files:
-<ul>
-<li>\c gui/wxpython/xml/main_menu.xml</li>
-<li>\c gui/wxpython/xml/toolboxes.xml</li>
-<li>\c gui/wxpython/xml/wxgui_items.xml</li>
-</ul>
-
-GRASS distribution contains these XML files:
-<ul>
-<li>\c etc/gui/wxpython/xml/main_menu.xml</li>
-<li>\c etc/gui/wxpython/xml/toolboxes.xml</li>
-<li>\c etc/gui/wxpython/xml/wxgui_items.xml</li>
-<li>\c etc/gui/wxpython/xml/module_items.xml (generated during compilation)</li>
-<li>\c etc/gui/wxpython/xml/menudata.xml (generated during compilation)</li>
-</ul>
-
-GRASS directory (\c ".grass7") in user home directory (i.e., \c "$HOME" on Unix)
-contains these XML files:
-<ul>
-<li>\c toolboxes/main_menu.xml (created by user)</li>
-<li>\c toolboxes/toolboxes.xml (created by user)</li>
-<li>\c toolboxes/menudata.xml (generated on wxGUI startup)</li>
-</ul>
-
-\dot
-digraph toolboxes {
-graph [rankdir="LR"];
-node [shape="record", style="rounded"];
-
-menudata [label="menudata.xml in distribution", shape="note", URL="\ref menudataFile"];
-umenudata [label="menudata.xml in user home", shape="note", URL="\ref menudataFile"];
-toolboxes [label="toolboxes.xml in distribution", shape="note", URL="\ref toolboxesFile"];
-utoolboxes [label="toolboxes.xml in user home", shape="note", URL="\ref toolboxesFile"];
-main_menu [label="main_menu.xml in distribution", shape="note", URL="\ref main_menuFile"];
-umain_menu [label="main_menu.xml in user home", shape="note", URL="\ref main_menuFile"];
-
-wxgui_items [label="wxgui_items.xml in distribution", shape="note", URL="\ref wxgui_itemsFile"];
-module_items [label="module_items.xml in distribution", shape="note", URL="\ref module_itemsFile"];
-
-menustrings [label="menustrings.py\n(used for translations)", shape="note"];
-
-module_items -> menudata;
-wxgui_items -> menudata;
-main_menu -> menudata;
-toolboxes -> menudata;
-
-module_items -> umenudata;
-wxgui_items -> umenudata;
-toolboxes -> umenudata;
-main_menu -> umenudata;
-umain_menu -> umenudata;
-utoolboxes -> umenudata;
-
-menudata -> menustrings;
-
-// guimenu [label="Main menu in wxGUI", shape="box3d"];
-// menustrings -> guimenu;
-// menudata -> guimenu;
-// umenudata -> guimenu;
-}
-\enddot
-
-
-\subsection toolboxesOtherFiles Other files
-
-GRASS source code contains these XML files:
-<ul>
-<li>\c gui/wxpython/xml/menudata_gmodeler.xml</li>
-<li>\c gui/wxpython/xml/menudata_psmap.xml</li>
-</ul>
-In GRASS distribution these XML files are in the \c etc/gui/wxpython/xml
-directory.
-
-
-\section toolboxesGeneration Generation of files and menu
-
-As noted in the section \ref toolboxesFilesOverview, there are files in the
-GRASS distribution and in the user home directory (particularly in
-\c ".grass7/tooboxes" subdirectory).
-
-When user doesn't have any \c toolboxes.xml or \c main_menu.xml files in the
-home directory, file \c menudata.xml included in the distribution is used to
-build a menu.
-
-When \c toolboxes.xml or \c main_menu.xml file (in user home directory) is newer
-than \c menudata.xml in user home directory or \c menudata.xml does not exists
-in user home directory, the \c menudata.xml is generated when GUI starts.
-
-When \c menudata.xml in user home directory is fresh enough,
-it is used to create a menu.
-
-When \c toolboxes.xml or \c main_menu.xml file is not in user home directory
-but \c menudata.xml is, the file is re-generated (each time the GUI starts).
-So, if you just have your own \c main_menu.xml, it is better to create also
-a \c toolboxes.xml file with no toolboxes (note that you still need to create
-a valid XML toolbox file).
-Similarly, if you have only the \c toolboxes.xml file it
-is better to copy the \c main_menu.xml file from distribution into your home
-directory.
-
-When reading the main_menu file, user toolboxes are expanded first and then
-toolboxes from distribution are expanded.
-
-
-\section toolboxesFile Toolboxes file
-
-This file contains definition of toolboxes. A toolbox contains references
-(links) to other items, namely \c "<module-items>", \c "<wxgui-items>"
-and other toolboxes using tag \c "<subtoolbox>". Tag \c "<separator>" is
-used when the view supports some kind of visual separators to group parts
-of the toolbox (or menu).
-
-Items are referenced using \c name attribute. In case of \c "<module-items>",
-\c "<wxgui-items>" also subelements can be added to create new items or to
-replace subelements values from item definition.
-
-\dot
-graph toolboxes {
-graph [rankdir="LR"];
-node [shape="record", style="rounded"];
-
-// ∞ causes Doxygen warning but it's harmless for dot and html output
-
-toolboxes -- toolbox [label="1..∞"];
-
-toolbox -- label;
-toolbox -- items [label="1..∞"];
-
-items -- "module-item" [label="0..1"];
-items -- "wxgui-item" [label="0..1"];
-items -- subtoolbox [label="0..1"];
-items -- separator [label="0..1"];
-
-milabel [label="label"];
-
-"module-item" -- milabel;
-"module-item" -- module [label="0..1"];
-"module-item" -- description [label="0..1"];
-"module-item" -- keywords [label="0..1"];
-
-wilabel [label="label"];
-widescription [label="description"];
-wikeywords [label="keywords"];
-
-"wxgui-item" -- wilabel [label="0..1"];
-"wxgui-item" -- handler [label="0..1"];
-"wxgui-item" -- "related-module" [label="0..1"];
-"wxgui-item" -- command [label="0..1"];
-"wxgui-item" -- widescription [label="0..1"];
-"wxgui-item" -- wikeywords [label="0..1"];
-"wxgui-item" -- shortcut [label="0..1"];
-"wxgui-item" -- "wx-id" [label="0..1"];
-}
-\enddot
-
-
-\section main_menuFile Main menu file
-
-File has a layout similar to the \ref toolboxesFile but contains only one
-<tt>toolbox</tt> which can contain only <tt>subtoolbox</tt>es and one special
-item <tt>user-toolboxes-list</tt> which will be replaced by a menu with the list
-of toolboxes in the user toolbox file.
-
-
-\section module_itemsFile Modules items file
-
-The file contains information obtained from modules' interface descriptions.
-The structure of one \c "module-item" is the same as in the \ref toolboxesFile
-but some subelements are mandatory.
-
-File contained in distribution is generated during compilation from available
-modules using the script \c gui/wxpython/tools/build_modules_xml.py.
-
-Element \c "<module>" is the name of the executable, e.g. "r.info".
-
-Element \c "<label>" is currently not present. It represents the short label in
-menu and it is added in toolboxes.
-
-Element \c "<description>" is created from module's module->description (or if
-it exists, module->label concatenated with module->description).
-
-Element \c "<keywords>" is created from module's module->keywords.
-
-
-\section wxgui_itemsFile wxGUI items file
-
-The file contains definitions of wxGUI actions which can be accessed for
-example, from menu.
-The structure of one \c "wxgui-item" is the same as in \ref toolboxesFile
-but some subelements are mandatory.
-
-
-\section menudataFile Menudata file
-
-Historically, menudata.xml file was in the source codes and was partially
-maintained by the script \c gui/wxpython/tools/update_menudata.py
-which updated the description and keywords (based on module's
-module->label or module->description, module->keywords).
-Other items (menu structure, menu item labels and non-module only items) were
-edited in the menudata.xml file directly.
-
-Currently, the file is generated during compilation or at startup. It serves
-as an intermediate layer between all toolboxes XMLs and GUI menu tree
-generation.
-
-
-\section howtotoolbox How to write a custom toolbox
-
-To create a new toolbox use \c "<toolbox>" tag:
-\verbatim
-<toolbox name="MyRaster">
-  <label>My &raster</label>
-  <items>
-    ...
-  </items>
-</toolbox>
-\endverbatim
-
-To create a new item which represents a module use \c "<module-item>" tag:
-\verbatim
-<module-item name="r.buffer">
-  <label>Buffer rasters</label>
-</module-item>
-\endverbatim
-This works for modules contained in distribution. For modules from addons or
-some your modules which are on path use \c "<module-item>" tag together with
-\c "<module>" tag:
-\verbatim
-<module-item name="r.agent">
-  <label>Buffer rasters</label>
-  <module>r.agent</module>
-</module-item>
-\endverbatim
-The name of a module is duplicated in the XML but anyway, try to keep \c name
-attribute and \c module element in sync.
-
-To create a new item which triggers some wxGUI action defined in distribution
-use \c "<wxgui-item>" tag:
-\verbatim
-<wxgui-item name="RasterMapCalculator"/>
-\endverbatim
-Note that now it is not possible to create custom wxGUI items.
-
-To include an existing toolbox use \c "<subtoolbox>" tag:
-\verbatim
-<subtoolbox name="NeighborhoodAnalysis"/>
-\endverbatim
-To create a submenu in your new menu (toolbox), you need to create a new toolbox
-and include this toolbox.
-
-To create your custom main menu create a file main_menu.xml in your user home
-directory, in \c .grass7/toolboxes subdirectory. Directory \c .grass7 may be
-hidden directory on your system. The XML file should contain the definition of
-only one toolbox. The name attribute and label element are not used but should
-be filled for documentation purposes and future compatibility.
-
-If you want to base your toolbox or main menu on existing toolbox or main menu
-copy the part of existing XML file from GRASS GIS distribution (installation)
-directory or GRASS GIS source code. If you want to include some existing
-toolboxes or wxGUI items defined in GRASS GIS you need to look to these files
-too and find the proper \c name attributes.
-
-
-\subsection howtotoolboxExample Example
-
-Files should be placed in user home directory in \c .grass7/toolboxes
-subdirectory, e.g. \c /home/john/.grass7/toolboxes.
-
-\par toolboxes.xml
-
-\verbatim
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE toolboxes SYSTEM "toolboxes.dtd">
-<toolboxes>
-  <toolbox name="MyRaster">
-    <label>My &raster</label>
-    <items>
-      <module-item name="r.buffer">
-        <label>Buffer rasters</label>
-      </module-item>
-      <module-item name="r.mask">
-        <label>Mask</label>
-      </module-item>
-      <separator/>
-      <wxgui-item name="RasterMapCalculator"/>
-      <subtoolbox name="NeighborhoodAnalysis"/>
-      <subtoolbox name="ReportAndStatistics"/>
-    </items>
-  </toolbox>
-</toolboxes>
-\endverbatim
-
-\par main_menu.xml
-
-\verbatim
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE toolbox SYSTEM "main_menu.dtd">
-<toolbox name="MyCustomMainMenu">
-  <label>MyCustomMainMenu</label>
-  <items>
-    <subtoolbox name="File"/>
-    <subtoolbox name="Settings"/>
-    <subtoolbox name="MyRaster"/>
-    <subtoolbox name="Imagery"/>
-    <subtoolbox name="Help"/>
-  </items>
-</toolbox>
-\endverbatim
-
-
-
-\subsection howtotoolboxValidation Validation
-
-You should validate your XML before running wxGUI, e.g. using \c xmllint
-(no output means that document is valid):
-\verbatim
-xmllint --noout --dtdvalid toolboxes.dtd toolboxes.xml
-\endverbatim
-
-You can find \c toolboxes.dtd and \c main_menu.dtd in your GRASS GIS directory,
-in \c etc/gui/wxpython/xml subdirectory.
-
-If you will provide an invalid, not well formed or empty file loading of
-toolboxes will obviously fail.
-
-
-\subsection howtotoolboxLabels Labels
-
-The label shortly describes the toolbox or the action which will happen after
-running an item. The label can be a command such as <i>"Create table"</i>
-or the general name such as <i>"Table management"</i>.
-You should add label to each toolbox you create and to each item you create.
-However, if you are just using (and thus referencing) existing items
-(or toolboxes), you don't need to include labels (so you can use just empty
-tags only with the name attribute).
-
-Important items in menu usually have a automatically assigned shortcut which
-depends on their label. This shortcut is assigned to <tt>Alt+Letter</tt>
-(On most platforms) where letter is a letter after an ampersand (\c &) in the
-item label and  in the user interface the letter is underlined.
-Note that in XML you cannot write \c "&" but you have to write \c "&".
-This concept is not related to the standard shortcut assigned to the item
-according to the shortcut in the XML file.
-
-Don't be confused with the label which is set for the module in the source code.
-
-*/
-

Deleted: grass/trunk/gui/wxpython/wxpythonlib.dox
===================================================================
--- grass/trunk/gui/wxpython/wxpythonlib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/gui/wxpython/wxpythonlib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,536 +0,0 @@
-/*! \page wxpythonlib GRASS wxPython-based GUI
-
-The GUI (Graphical User Interface) is written in the Python
-programming language using <a
-href="http://www.wxpython.org">wxPython</a> library - a blending of
-the <a href="http://www.wxwidgets.org">wxWidgets</a> library for
-Python.
-
-The wxPython GUI (so called <em>wxGUI</em>) is composed of two main
-<em>components</em>:
-
-- <b>Layer Manager</b> and
-- <b>Map Display Window</b>.
-
-The <em>Layer Manager</em> allows users to run different GRASS modules
-from a menu, includes map layer management, integrated command-line
-prompt, and command output window. The <em>Map Display Window</em>
-integrates basic tools for zooming, panning, data querying,
-decorations (north arrows, barscale, etc.). Additional tools like
-vector digitizer or georectification tool are also available.
-
-
-\tableofcontents
-
-\par Related pages
-\subpage wxguitoolboxes
-
-
-\section background Background
-
-The plan for a native GUI for GRASS found its origin in the project <a
-href="http://geo.fsv.cvut.cz/~landa/publications/2008/unpublished/fbk-report/technology-for-geoinformatics.html">GFOSS-TN</a>,
-a collaboration between <a href="http://www.fbk.eu">FBK</a>
-(Fondazione Bruno Kessler) and the Information System Service of the
-Trento municipality (Italy). The wxGUI is successor of Tcl/Tk GUI
-available in GRASS 5 and GRASS 6.
-
-\section classes List of Modules and Classes
-
-\subsection core Core modules
-
-- core::debug
- - debug::DebugMsg
-- core::globalvar
-- core::gcmd
- - gcmd::GError
- - gcmd::GWarning
- - gcmd::GMessage
- - gcmd::GException
- - gcmd::Popen
- - gcmd::Command
- - gcmd::CommandThread
-- core::gconsole
- - goutput::CmdThread
- - goutput::GStdout
- - goutput::GStderr
- - goutput::GConsole
-- core::menutree
- - menutree::MenuTreeModelBuilder
-- core::modulesdata
- - modulesdata::ModulesData
-- core::render
- - render::Layer
- - render::MapLayer
- - render::Overlay
- - render::Map
-- core::settings
- - settings::Settings
-- core::units
- - units::BaseUnits
-- core::utils
-- core::workspace
- - workspace::ProcessWorkspaceFile
- - workspace::WriteWorkspaceFile
- - workspace::ProcessGrcFile
-
-\subsection gui_core GUI core modules
-
-- gui_core::dialogs
- - dialogs::SimpleDialog
- - dialogs::LocationDialog
- - dialogs::MapsetDialog
- - dialogs::NewVectorDialog
- - dialogs::SavedRegion
- - dialogs::DecorationDialog
- - dialogs::TextLayerDialog 
- - dialogs::GroupDialog
- - dialogs::MapLayersDialog
- - dialogs::ImportDialog
- - dialogs::GdalImportDialog
- - dialogs::GdalOutputDialog
- - dialogs::DxfImportDialog
- - dialogs::LayersList (used by MultiImport) 
- - dialogs::SetOpacityDialog
- - dialogs::StaticWrapText
- - dialogs::ImageSizeDialog
- - dialogs::SqlQueryFrame
- - dialogs::SymbolDialog
-- gui_core::forms
- - forms::TaskFrame
- - forms::CmdPanel
- - forms::GrassGUIApp
-- gui_core::ghelp
- - ghelp::AboutWindow
- - ghelp::HelpFrame
- - ghelp::HelpWindow
- - ghelp::HelpPanel
-- gui_core::goutput
- - goutput::GConsoleWindow
- - goutput::GStc
-- gui_core::gselect
- - gselect::Select
- - gselect::VectorSelect
- - gselect::TreeCrtlComboPopup
- - gselect::VectorDBInfo
- - gselect::LayerSelect
- - gselect::DriverSelect
- - gselect::DatabaseSelect
- - gselect::ColumnSelect
- - gselect::DbaseSelect
- - gselect::LocationSelect
- - gselect::MapsetSelect
- - gselect::SubGroupSelect
- - gselect::FormatSelect
- - gselect::GdalSelect
- - gselect::ProjSelect
- - gselect::ElementSelect
- - gselect::OgrTypeSelect
-- gui_core::mapdisp
- - mapdisp::MapFrameBase
- - mapdisp::SingleMapFrame
- - mapdisp::DoubleMapFrame
-- gui_core::mapwindow
- - mapwindow::MapWindow
-- gui_core::menu
- - menu::Menu
- - menu::SearchModuleWindow
-- gui_core::preferences
- - preferences::PreferencesBaseDialog
- - preferences::PreferencesDialog
- - preferences::DefaultFontDialog
- - preferences::MapsetAccess
-- gui_core::prompt
- - prompt::GPrompt
- - prompt::GPromptSTC
-- gui_core::query
- - query::QueryDialog
-- gui_core::toolbars
- - toolbars::BaseToolbar
-- gui_core::treeview
- - treeview::TreeView
-- gui_core::widgets
- - widgets::ScrolledPanel
- - widgets::NTCValidator
- - widgets::SimpleValidator
- - widgets::NumTextCtrl
- - widgets::FloatSlider
- - widgets::SymbolButton
- - widgets::StaticWrapText
- - widgets::BaseValidator
- - widgets::IntegerValidator
- - widgets::FloatValidator
- - widgets::NTCValidator
- - widgets::SearchModuleWidget
-
-\subsection lmgr Layer Manager
-
-- wxgui
- - wxgui::GMApp
- - wxgui::Usage
-- lmgr::layertree
- - lmgr::LayerTree
-- lmgr::menudata
- - menudata::LayerManagerMenuData
-- lmgr::pyshell
- - pyshell::PyShellWindow
-- lmgr::toolbars
- - toolbars::LMWorkspaceToolbar
- - toolbars::LMDataToolbar
- - toolbars::LMToolsToolbar
- - toolbars::LMMiscToolbar
- - toolbars::LMVectorToolbar
- - toolbars::LMNvizToolbar
-- lmgr::frame
- - frame::GMFrame
-
-\subsection mapdisp Map Display Window
-
-- mapdisp::frame
- - mapdisp::MapFrame
- - mapdisp::MapApp
-- mapdisp::gprint
- - gprint::MapPrint
- - gprint::PrintOptions
-- mapdisp::mapwindow
- - mapwindow::BufferedWindow
-- mapdisp::statusbar
- - statusbar::SbException
- - statusbar::SbManager
- - statusbar::SbItem
- - statusbar::SbRender
- - statusbar::SbShowRegion
- - statusbar::SbAlignExtent
- - statusbar::SbResolution
- - statusbar::SbMapScale
- - statusbar::SbGoTo
- - statusbar::SbProjection
- - statusbar::SbMask
- - statusbar::SbTextItem
- - statusbar::SbDisplayGeometry
- - statusbar::SbCoordinates
- - statusbar::SbRegionExtent
- - statusbar::SbCompRegionExtent
- - statusbar::SbProgress
-- mapdisp::toolbars
- - toolbars::MapToolbar
-
-\subsection wscreen Welcome screen
-
-- gis_set_error
-- gis_set
- - gis_set::GRASSStartup
- - gis_set::StartUp
- - gis_set::GListBox
-
-\subsection dbmgr Database Manager
-
-- dbmgr::dialogs
- - dialogs::DisplayAttributesDialog
- - dialogs::ModifyTableRecord
-- dbmgr::manager
- - manager::Log
- - manager::VirtualAttributeList
- - manager::AttributeManager
- - manager::TableListCtrl
- - manager::LayerListCtrl
- - manager::LayerBook
-- dbmgr::sqlbuilder
- - sqlbuilder::SQLFrame
-- dbmgr::vinfo
- - vinfo::VectorDBInfo
-
-\subsection gpc Georectifier
-
-- gcp::manager
- - manager::GCPWizard
- - manager::LocationPage
- - manager::GroupPage
- - manager::DispMapPage
- - manager::GCP
- - manager::GCPList
- - manager::VectGroup
- - manager::EditGCP
- - manager::GrSettingsDialog
-- gcp::mapdisplay
-- mapdisplay::MapFrame
-- gcp::toolbars
- - toolbars::GCPMapToolbar
- - toolbars::GCPDisplayToolbar
-
-\subsection gmodeler Graphical Modeler
-
-- gmodeler::dialogs
- - dialogs::ModelDataDialog
- - dialogs::ModelSearchDialog
- - dialogs::ModelRelationDialog
- - dialogs::ModelItemDialog
- - dialogs::ModelLoopDialog
- - dialogs::ModelConditionDialog
- - dialogs::ModelListCtrl
- - dialogs::ValiableListCtrl
- - dialogs::ItemListCtrl
- - dialogs::ItemCheckListCtrl
-- gmodeler::frame
- - frame::ModelToolbar
- - frame::ModelFrame
- - frame::ModelCanvas
- - frame::ModelEvtHandler
- - frame::VariablePanel
- - frame::ItemPanel
- - frame::PythonPanel
-- gmodeler::menudata
- - menudata::ModelerMenuData
-- gmodeler::model
- - model::Model
- - model::ModelObject
- - model::ModelAction
- - model::ModelData
- - model::ModelRelation
- - model::ModelItem
- - model::ModelLoop
- - model::ModelCondition
- - model::ProcessModelFile
- - model::WriteModelFile
- - model::WritePythonFile
- - model::ModelParamDialog
-- gmodeler::preferences
- - preferences::PreferencesDialog
- - preferences::PropertiesDialog
-- gmodeler::pystc
- - pystc::PyStc
-
-\subsection vdigit Vector digitizer
-
-- vdigit::dialogs
- - dialogs::VDigitCategoryDialog
- - dialogs::CategoryListCtrl
- - dialogs::VDigitZBulkDialog
- - dialogs::VDigitDuplicatesDialog
- - dialogs::CheckListFeature
-- vdigit::main
- - main::VDigit
-- vdigit::mapwindow
- - mapwindow::VDigitWindow
-- vdigit::preferences
- - preferences::VDigitSettingsDialog
-- vdigit::toolbars
- - toolbars::VDigitToolbar
-- vdigit::wxvdigit
- - wxdigit::VDigitError
- - wxdigit::IVDigit
-- vdigit::wxdisplay
- - wxdisplay::DisplayDriver
-
-\subsection wxnviz 3D view mode (wxNviz)
-
-- nviz::animation
- - animation::Animation
-- nviz::main
-- nviz::mapwindow
- - mapwindow::NvizThread
- - mapwindow::GLWindow
-- nviz::preferences
- - preferences::NvizPreferencesDialog
-- nviz::tools
- - tools::NvizToolWindow
- - tools::PositionWindow
- - tools::ViewPositionWindow
- - tools::LightPositionWindow
-- nviz::workspace
- - workspace::NvizSettings
-- nviz::wxnviz
- - wxnviz::Nviz
- - wxnviz::Texture
- - wxnviz::ImageTexture
- - wxnviz::TextTexture
-
-\subsection psmap Cartograpic Composer
-
-- psmap::dialogs
- - dialogs::TCValidator
- - dialogs::PenStyleComboBox
- - dialogs::CheckListCtrl
- - dialogs::PsmapDialog
- - dialogs::PageSetupDialog
- - dialogs::MapDialog
- - dialogs::MapFramePanel
- - dialogs::RasterPanel
- - dialogs::VectorPanel
- - dialogs::RasterDialog
- - dialogs::MainVectorDialog
- - dialogs::VPropertiesDialog
- - dialogs::LegendDialog
- - dialogs::MapinfoDialog
- - dialogs::ScalebarDialog
- - dialogs::TextDialog
- - dialogs::ImageDialog
- - dialogs::NorthArrowDialog
-- psmap::instructions
- - dialogs::Instruction
- - dialogs::InstructionObject
- - dialogs::InitMap
- - dialogs::MapFrame
- - dialogs::PageSetup
- - dialogs::Mapinfo
- - dialogs::Text
- - dialogs::Image
- - dialogs::NorthArrow
- - dialogs::Point
- - dialogs::Line
- - dialogs::Rectangle
- - dialogs::Scalebar
- - dialogs::RasterLegend
- - dialogs::VectorLegend
- - dialogs::Raster
- - dialogs::Vector
- - dialogs::VProperties
-- psmap::utils
- - utils::Rect2D
- - utils::Rect2DPP
- - utils::Rect2DPS
- - utils::UnitConversion
-- psmap::frame
- - frame::PsMapFrame
- - frame::PsMapBufferedWindow
-- psmap::menudata
- - menudata::PsMapMenuData
-- psmap::toolbars
- - toolbars::PsMapToolbar
-
-\subsection locWizard Location Wizard
-
-- location_wizard::base
- - location_wizard::BaseClass
-- location_wizard::dialogs
- - dialogs::RegionDef
- - dialogs::TransList
- - dialogs::SelectTransformDialog
-- location_wizard::wizard
- - wizard::TitledPage
- - wizard::DatabasePage
- - wizard::CoordinateSystemPage
- - wizard::ProjectionsPage
- - wizard::ItemList
- - wizard::ProjParamsPage
- - wizard::DatumPage
- - wizard::EllipsePage
- - wizard::GeoreferencedFilePage
- - wizard::EPSGPage
- - wizard::CustomPage
- - wizard::SummaryPage
- - wizard::LocationWizard
-
-\subsection plot Plotting modules
-
-- wxplot::base
- - base::BasePlotFrame
-- wxplot::dialogs
- - dialogs::ProfileRasterDialog
- - dialogs::ScatterRasterDialog
- - dialogs::PlotStatsFrame
- - dialogs::HistRasterDialog
- - dialogs::TextDialog
- - dialogs::OptDialog
-- wxplot::histogram
- - histogram::Histogram2Frame
- - histogram::Histogram2Toolbar
-- wxplot::profile
- - profile::ProfileFrame
- - profile::ProfileToolbar
-- wxplot::scatter
- - scatter::ScatterFrame
- - scatter::ScatterToolbar
-
-\subsection wxIClass wxIClass
-- iclass::dialogs
- - dialogs::IClassGroupDialog
- - dialogs::IClassMapDialog
- - dialogs::IClassCategoryManagerDialog
- - dialogs::CategoryListCtrl
- - dialogs::IClassSignatureFileDialog
-- iclass::digit
- - digit::IClassVDigit
- - digit::IClassVDigitWindow
-- iclass::frame
- - frame::IClassMapFrame
- - frame::MapManager
-- iclass::plots
- - plots::PlotPanel
-- iclass::statistics
- - statistics::Statistics
- - statistics::BandStatistics
-- iclass::toolbars
- - toolbars::IClassMapToolbar
- - toolbars::IClassToolbar
- - toolbars::IClassMapManagerToolbar
- - toolbars::IClassMiscToolbar
-
-\subsection mapswipe Map Swipe
-
-- mapswipe::frame
- - frame::SwipeMapFrame
- - frame::MapSplitter
-- mapswipe::mapwindow
- - mapwindow::SwipeBufferedWindow
- - mapwindow::_MouseEvent
-- mapswipe::dialogs
- - dialogs::SwipeMapDialog
-- mapswipe::toolbars
- - toolbars::SwipeMapToolbar
- - toolbars::SwipeMainToolbar
- - toolbars::SwipeMiscToolbar
-
-\subsection other Other GUI modules
-
-- modules::colorrules
- - colorrules::RulesPanel
- - colorrules::ColorTable
- - colorrules::RasterColorTable
- - colorrules::VectorColorTable
- - colorrules::ThematicVectorTable
- - colorrules::BufferedWindow
-- modules::extensions
- - extensions::InstallExtensionWindow
- - extensions::ExtensionTree
- - extensions::UninstallExtensionWindow
- - extensions::CheckListExtension
-- modules::histogram
- - histogram::BufferedWindow
- - histogram::HistogramFrame
- - histogram::HistogramToolbar
-- modules::mcalc_builder
- - mcalc_builder::MapCalcFrame
-- modules::ogc_services
- - ogc_services::WMSDialog
- - ogc_services::LayersList
-- modules::vclean
- - vclean::VectorCleaningFrame
-
-\section devel Further Development
-
-Ongoing development focuses on stability, portability and on the
-integration of OpenGL (see \ref wxnviz).
-
-A Map Composer, a tool for hardcopy map outputs is also planned to be
-developed. Currently, the tools for creating hardcopy maps (map
-layout) are limited in GRASS because its focus on modeling and spatial
-analysis. GRASS gives the user ability to add only a very simple and
-standardized legend, north arrow and scale to display to the graphics
-monitor and then export the display to an external image file such as
-a png. These map features are very basic and cannot be customized. The
-goal is to allow users to prepare simple cartographic outputs
-comparable e.g. with other, proprietary GIS map layout functionality.
-
-For more info see http://trac.osgeo.org/grass/wiki/wxGUIDevelopment
-
-\section seeAlso See also
-
-- GRASS User Wiki - http://grass.osgeo.org/wiki/WxGUI
-- GRASS Devs Wiki - http://trac.osgeo.org/grass/wiki/wxGUIDevelopment
-
-\section refs References
-
-- M. Landa, C. Moretto, M. Neteler, M. Zanolli, L. Manganelli, 2008: wxPython GUI per GRASS GIS. Proc. IX Meeting degli Utenti Italiani di GRASS - GFOSS - 21-22 Feb 2008, Perugia, Italy (<a href="http://geo.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf">PDF</a>)
-
-*/

Modified: grass/trunk/include/Make/Docs.make
===================================================================
--- grass/trunk/include/Make/Docs.make	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/include/Make/Docs.make	2014-09-26 18:57:08 UTC (rev 62097)
@@ -21,12 +21,10 @@
 	lib/gmath \
 	lib/gpde \
 	lib/proj \
-	lib/python \
 	lib/ogsf \
 	lib/segment \
 	lib/vector \
-	lib/vector/dglib \
-	gui/wxpython
+	lib/vector/dglib
 
 htmldocs_dirs := $(patsubst %,%/html,$(docs_dirs))
 latexdocs_dirs := $(patsubst %,%/latex,$(docs_dirs))

Modified: grass/trunk/include/Make/Doxyfile_arch_html.in
===================================================================
--- grass/trunk/include/Make/Doxyfile_arch_html.in	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/include/Make/Doxyfile_arch_html.in	2014-09-26 18:57:08 UTC (rev 62097)
@@ -683,11 +683,7 @@
                          dist. at ARCH@ \
                          doc \
                          general \
-                         gui/scripts \
-                         gui/wxpython/compat \
-                         gui/wxpython/icons \
-                         gui/wxpython/scripts \
-                         gui/wxpython/tools \
+                         gui \
                          imagery \
                          include/defs \
                          lib/btree/test \
@@ -697,7 +693,7 @@
                          lib/gpde/test \
                          lib/linkm/test \
                          lib/raster3d/test \
-                         lib/python/ctypes \
+                         lib/python \
                          lib/vector/dglib/examples \
                          lib/vector/rtree/docs \
                          locale \
@@ -739,8 +735,7 @@
                          */testsuite/* \
                          */test_* \
                          */test.* \
-                         */*local_proto.h \
-                         */g.gui.*.py
+                         */*local_proto.h
 
 # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
 # (namespaces, classes, functions, etc.) that should be excluded from the

Modified: grass/trunk/include/Make/Doxyfile_arch_latex.in
===================================================================
--- grass/trunk/include/Make/Doxyfile_arch_latex.in	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/include/Make/Doxyfile_arch_latex.in	2014-09-26 18:57:08 UTC (rev 62097)
@@ -683,11 +683,7 @@
                          dist. at ARCH@ \
                          doc \
                          general \
-                         gui/scripts \
-                         gui/wxpython/compat \
-                         gui/wxpython/icons \
-                         gui/wxpython/scripts \
-                         gui/wxpython/tools \
+                         gui \
                          imagery \
                          include/defs \
                          lib/btree/test \
@@ -697,7 +693,7 @@
                          lib/gpde/test \
                          lib/linkm/test \
                          lib/raster3d/test \
-                         lib/python/ctypes \
+                         lib/python \
                          lib/vector/dglib/examples \
                          lib/vector/rtree/docs \
                          locale \
@@ -739,8 +735,7 @@
                          */testsuite/* \
                          */test_* \
                          */test.* \
-                         */*local_proto.h \
-                         */g.gui.*.py
+                         */*local_proto.h
 
 # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
 # (namespaces, classes, functions, etc.) that should be excluded from the

Modified: grass/trunk/lib/python/ctypes/Makefile
===================================================================
--- grass/trunk/lib/python/ctypes/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/ctypes/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -3,12 +3,7 @@
 PACKAGE = "grasslibs"
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
-# doxygen:
-DOXNAME=
-DOXINPUT=grasspython.dox
-
 MODULES = date gis raster gmath proj imagery vector rtree display stats \
 	dbmi raster3d arraystats cluster vedit ogsf nviz segment rowio temporal
 

Modified: grass/trunk/lib/python/imaging/Makefile
===================================================================
--- grass/trunk/lib/python/imaging/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/imaging/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -2,7 +2,6 @@
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
 PYDIR = $(ETC)/python
 GDIR = $(PYDIR)/grass
@@ -10,7 +9,6 @@
 
 MODULES = images2avi images2gif images2ims images2swf
 
-
 PYFILES := $(patsubst %,$(DSTDIR)/%.py,$(MODULES) __init__)
 PYCFILES := $(patsubst %,$(DSTDIR)/%.pyc,$(MODULES) __init__)
 
@@ -27,6 +25,3 @@
 
 $(DSTDIR)/%: % | $(DSTDIR)
 	$(INSTALL_DATA) $< $@
-
-#doxygen:
-DOXNAME = imaginglib

Deleted: grass/trunk/lib/python/imaging/imaginglib.dox
===================================================================
--- grass/trunk/lib/python/imaging/imaginglib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/imaging/imaginglib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,33 +0,0 @@
-/*! \page imaging Python library for animations
-
-
-\tableofcontents
-
-
-\section imagingIntro Introduction
-Library python.imaging is a third-party python library for animations.
-It comes from visvis project (https://code.google.com/p/visvis/), version 1.8.
-Library contains 4 main files: images2avi.py, images2gif.py, images2ims.py, images2swf.py for exporting
-AVI video file, animated GIF, series of images and SWF file format, respectively.
-There are functions for reading/writing those formats (writeAvi(), readAvi(), writeGif(), readGif(),
-writeIms(), readIms(), writeSwf(), readSwf()). Library requires PIL (Python Imaging Library) and numpy packages.
-The input of all write functions are PIL images.
-
-Please read README in library's directory.
-
-Example:
-
-\code{.py}
-from grass.imaging import writeIms
-...
-writeIms(filename=path/to/directory/anim.png, images=myPILImagesList)
-\endcode
-
-This creates files anim1.png, anim2.png, ... in path/to/directory.
-
-
-\section imagingAuthors Authors
-
-Almar Klein (see licence in header of library files)
-
-*/

Modified: grass/trunk/lib/python/pydispatch/Makefile
===================================================================
--- grass/trunk/lib/python/pydispatch/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/pydispatch/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -2,7 +2,6 @@
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
 PYDIR = $(ETC)/python
 GDIR = $(PYDIR)/grass
@@ -10,7 +9,6 @@
 
 MODULES = dispatcher errors robustapply robust saferef signal
 
-
 PYFILES := $(patsubst %,$(DSTDIR)/%.py,$(MODULES) __init__)
 PYCFILES := $(patsubst %,$(DSTDIR)/%.pyc,$(MODULES) __init__)
 
@@ -27,6 +25,3 @@
 
 $(DSTDIR)/%: % | $(DSTDIR)
 	$(INSTALL_DATA) $< $@
-
-#doxygen:
-DOXNAME = pydispatchlib

Deleted: grass/trunk/lib/python/pydispatch/pydispatchlib.dox
===================================================================
--- grass/trunk/lib/python/pydispatch/pydispatchlib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/pydispatch/pydispatchlib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,208 +0,0 @@
-/*! \page pydispatch PyDispatcher library and Signal API
-
-by GRASS Development Team (http://grass.osgeo.org)
-
-\tableofcontents
-
-
-\section pydispatchIntro Introduction
-
-Simple function calls are not sufficient in the GUI, event driven and large environment with many persistent objects because using simple function calls would lead to tightly coupled code. Thus, some better mechanism is needed such as Observer design pattern. We decided to use Signal system which is similar to Signals used in PyQt and other frameworks. As the underlying library, we have chosen PyDispatcher because it provides very general API which enables to implement Signal API, wide and robust functionality which makes implementation and use of Signals easier.
-
-Files dispatcher.py, errors.py, robustapply.py, robust.py and saferef.py are
-part of the original PyDispatcher library.
-File signal.py is the object-based easy-to-use interface created for GRASS.
-
-Signals as a concept (API) does not depend on PyDispatcher,
-so PyDipacher can be replaced by something else if necessary (in theory even with wx events).
-Of course, the API of underling library has to be general enough and some small changes in Signal API can occur.
-Nevertheless, it is important that Signals as a concept can be used with other library.
-
-Signals and PyDispatcher do not depend on wxPython, so it can be used even for non-GUI code (this allows to use controller classes to create command line tools).
-
-
-\section pydispatchSignal Signal addition to the original PyDispatcher
-
-The python.pydispatch.signal.Signal (grass.pydispatch.signal.Signal) class is the simplified API to the PyDispatcher library.
-It provides subset of minimal functionality.
-However, this subset should be enough to solve most of the problems.
-The main advantages of Signals are the readable syntax and more importantly,
-the understandable resulting design.
-
-Signal represents a message which will be sent at some point.
-Message usually informs about something which has happened.
-However, it is not necessary.
-A message can also say that something will happen or that we want something to happen.
-
-The Signal API is similar to Signal as used in PyQt, PySide.
-Some other frameworks (not necessarily Python one) support the similar set of functions but with more different names.
-
-
-\note Only Signal API should be used from this library to ensure consistency in design and variability in underlying library choice.
-
-
-\section pydispatchObserver Observer design pattern
-
-To get complete understanding of the signals system it is advised to understand observer design pattern.
-This design pattern is sometimes called Listener, Observer/Observable or Publisher/Subscriber.
-The main point is that it is nothing else than another view of the signals or events mechanisms.
-
-The basic schema follows.
-The Observable object holds the list of registered handlers and Observers register itself (or its methods) as these handlers. Once something interesting happens in the Observable, Observable notifies all its Observers.
-
-To avoid ad hoc observer implementation this and there, it is better to have universal reusable system such as Signals.
-
-
-\section pydispatchNaming Naming
-
-The occasion when something happens is called event or signal. The preferred word is signal.
-
-The word for actual triggering of the event is post, send, emit or notify.
-The process itself can be called sending a message.
-The preferred word is emit.
-
-The method called when event occurs is called handler, receiver, listener, observer, slot or callback.
-In some systems, there have to be receiver object and receiver function but in Python this is usually not the case.
- The preferred word is handler (but may change).
-
-The association of the signal to the handler is called connecting, binding, registration or subscription.
-The preferred word is connecting but registration is also acceptable.
-
-
-\section pydispatchWhyBetter Why are Signals better than wx events
-
-Here is the list of points why is the PyDispatcher with the custom Signal API better and more advantageous than wx event system when used to connect newly designed classes in wxGUI code. Some points may overlap, however the main point is that the wx event system is very complicated and cumbersome.
-
-<ul>
-<li>It is not possible to unbind one specific event handler.
-Unbinding always unbinds all registered handlers. As a consequence, you need to create some handler registration system on your own for some special cases such as dynamic registration to mouse clicks at.</li>
-<li>wx events always need a receiver to be posted.
-The binding of an event has to be always associated to some object, too.
-Thus, when writing post and bind, you need to take care of two things -- the receiver and the event itself.</li>
-<li>Command events work only with wx.Windows, not wx.EvtHandlers,
-so for other objects than windows you need to have extra parameter (so called guiparent) which can be used for posting command events.</li>
-<li>Command events are propagated to parent windows (buttons, panels and frames).
-However, they do not propagate beyond dialogs (dialog stops the propagation). Events (standard ones) do not propagate at all.</li>
-<li>Signal is independent concept which can be implemented in various ways.</li>
-<li>When using wx events, there is a different object to post the event and to bind a event.
-Moreover, you can bind a handler to non-existing event.
-Signals, on the other hand, have much cleaner syntax which can be checked easily.
-There is only one object and the rest are standard function calls.</li>
-<li>It is not possible to track how the wx event goes. Tracking the signal is possible.
-(But this is might be related to the fact that we can change and control the Signal code.)</li>
-<li>Parameters of wx event handlers have to be attributes of event object.
-So, it is not possible to have standard function as event handler (you can overcome this using a lambda function).
-On the other hand, using Signals any keywords arguments can be passed.</li>
-<li>It is easy to forward one Signal to another.
-This feature is more important for Signals than for wx events but once it is available it is generally useful.
-Using lambda functions, it is possible to change keyword argument names.</li>
-<li>The design of resulting system using Signals is much clearer than using wx events.
-There are no consideration about propagation; it is explicit and clear who receives the signal.
-Handlers does not have to consider if event must be forwarded or ended.
-Considering all this, it is very difficult to use the wx event system right.</li>
-</ul>
-
-As a concluding note, we can say that many of the wx events disadvantages are more or less copied from GRASS documentation where the wx event system was explained. This is pretty scary.
-
-
-\section pydispatchCodeComparison Signals and wx events code comparison
-
-\code{.py}
-# import
-
-from grass.pydispatch.signal import Signal  # Signal
-from wx.lib.newevent import NewEvent  # wx event
-
-
-# the signal/event definition
-
-# usually before class definition
-gMapCreated, EVT_MAP_CREATED = NewEvent()  # wx event
-
-# somewhere in the class
-self.mapCreated = Signal('GConsole.mapCreated')  # Signal
-
-
-# in some method which emits signal/event (in some class)
-
-# signal
-self.mapCreated.emit(name=name, ltype=prompt)
-
-# wx event
-mapEvent = gMapCreated(self._guiparent.GetId(),
-                       name=name, ltype=prompt)
-wx.PostEvent(self._guiparent, mapEvent)
-
-
-# connection in some __init__ (in some other class)
-self._gconsole.mapCreated.connect(self.OnMapCreated)  # signal
-self.Bind(EVT_MAP_CREATED, self.OnMapCreated)  # wx event
-
-
-# handler (in the other class)
-
-# signal
-def OnMapCreated(self, name, ltype):
-    doSomethinUseful(name, ltype)
-    # in this case function could be connected directly
-
-# wx event
-def OnMapCreated(self, event):
-    doSomethingUseful(event.name, event.ltype)
-    event.Skip()  # sometimes yes, sometimes no
-\endcode
-
-When a method does not take any parameters, no additional work is needed when using Signals.
-A handler can be connected directly to a signal (even if the signal has some parameters).
-\code{.py}
-def someMethod(self):
-    """Method without parameters."""
-
-something.someSignal.connect(self.someMethod)  # signal
-something.Bind(EVT_SOMETHING, lambda event: self.someMethod())  # wx event
-\endcode
-
-
-\section pydispatchWhereUse Where to use Signals rather than wx events
-
-Signals should be used for all non-GUI objects. Moreover, no new wx events shall be defined. The Signals should be used instead.
-
-wx events should be used only when binding to existing wxPython GUI objects. For controlling the graphical objects on the library level, the wx events are necessary.
-
-
-\section pydispatchDisadvantages Signals and PyDispatcher disadvantages
-
-<ul>
-<li>Propagation of the signal cannot be stopped. All connected handlers are called.
-(For example, wx events provides the functionality to choose if event should be propagated or not.)</li>
-<li>There is no automatic propagation through the object hierarchy.
-Signals have to be always forwarded manually.
-However, this is big disadvantage only for GUI events such as propagation of key stroke, for this wx events are used in wxPython anyway.</li>
-<li>The order of handler calls is not defined. In fact, it is defined but the definition is unknown.</li>
-<li>PyDispatcher or some other library have to be included in GRASS to make Signals work.</li>
-</ul>
-
-It must be noted that non-stoppable propagation, no auto-propagation and no information about order of handlers leads to better code design
-because if you don't rely on these features, you usually write a less tangled code.
-
-
-\section pydispatchAlternatives Alternatives
-
-There is wxPython's pubsub module which provides similar functionality to PyDispatcher. However, it has two incompatible APIs which depends on the wxPython version and in the time of writing, GRASS would have to support both these APIs. The only possibility is to include pubsub into GRASS. Whether to use PyDispatcher or pubsub usually depends on personal taste.
-
-There are several forks of PyDispatcher, e.g. the fork in Django framework.
-They provide the same or similar functionality.
-
-Of course it is also possible to implement this system from the scratch using e.g., observer pattern.
-Although it is possible it becomes more complicated when the system has to be generalized.
-
-
-\section pydispatchAuthors Authors
-
-Patrick K. O'Brien, Mike C. Fletcher and Contributors (original authors, see pydispatch/license.txt and pydispatch/PKG-INFO for details)
-
-Vaclav Petras (signal.py)
-
-Anna Kratochilova (signal.py)
-
-*/

Modified: grass/trunk/lib/python/pygrass/Makefile
===================================================================
--- grass/trunk/lib/python/pygrass/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/pygrass/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -2,7 +2,6 @@
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
 PYDIR = $(ETC)/python
 GDIR = $(PYDIR)/grass
@@ -35,6 +34,3 @@
 
 $(DSTDIR)/%: % | $(DSTDIR)
 	$(INSTALL_DATA) $< $@
-
-#doxygen:
-DOXNAME = pygrass

Deleted: grass/trunk/lib/python/pygrass/pygrasslib.dox
===================================================================
--- grass/trunk/lib/python/pygrass/pygrasslib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/pygrass/pygrasslib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,173 +0,0 @@
-/*! \page pygrasslib PyGRASS Library
-
-by GRASS Development Team (http://grass.osgeo.org)
-
-\section pygrassIntro Introduction
-
-PyGRASS improves the integration between GRASS GIS and Python (see 
-also \ref pythonlib), making the use of Python under GRASS more 
-consistent with the language itself. Furthermore, it simplifies 
-GRASS scripting and programming and more natural for the user.
-
-\section pygrassPackages PyGRASS packages 
-
-The following PyGRASS packages are provided:
- - \subpage pygrassGis
- - \subpage pygrassRaster
- - \subpage pygrassVector
- - \subpage pygrassModule
- - \subpage pygrassFunctions
- - \subpage pygrassMessages
- - \subpage pygrassErrors
- 
- Below these packages are illustrated in greater detail.
-
-\subsection pygrassGis GIS Package
-
- - python::pygrass::gis
-
-Basic elements of the GRASS data-base:
-
-  - python::pygrass::gis::Gisdbase
-  - python::pygrass::gis::Location
-  - python::pygrass::gis::Mapset
-  - python::pygrass::gis::VisibleMapset
-
-Computational region:
-
-  - python::pygrass::gis::region::Region
-
-Mapset handling:
-     
-  - python::pygrass::gis::set_current_mapset
-  - python::pygrass::gis::make_mapset
-
-\subsection pygrassRaster Raster Package
-
-PyGRASS uses 4 different Raster classes, that respect the 4 
-different approaches of GRASS-C API. The read access is row wise for 
-RastRow and RasterRowIO and additionally cached in the RowIO class. 
-Both classes write sequentially. RowIO is row cached, RastSegment 
-and RasterNumpy are tile cached for reading and writing therefore a 
-randomly access is possible. Hence RasterRow and RasterRowIO should 
-be used in case for fast (cached) row read access and RasterRow for 
-fast sequential writing. Segment and Numpy should be used for random 
-access, but Numpy only for files not larger than 2GB.
-
- - python::pygrass::raster
-
-Reading/writing raster maps:
-
-  - python::pygrass::raster::RasterRow
-  - python::pygrass::raster::RasterRowIO
-  - python::pygrass::raster::RasterSegment
-  - python::pygrass::raster::RasterNumpy
-
-Random raster data:
-     
-  - python::pygrass::raster::random_map_only_columns
-  - python::pygrass::raster::random_map
-
-Raster categories:
-
-  - python::pygrass::raster::category::Category
-
-Raster metadata:
-
-  - python::pygrass::raster::history::History
-
-\subsection pygrassVector Vector Package
-
- - python::pygrass::vector
-
-List of high-level classes:
-
-  - python::pygrass::vector::Vector
-  - python::pygrass::vector::VectorTopo
-
-Basic data structures and functions:
-
- - python::pygrass::vector::basic
-  - python::pygrass::vector::basic::Bbox
-  - python::pygrass::vector::basic::BoxList
-  - python::pygrass::vector::basic::Cats
-  - python::pygrass::vector::basic::CatsList
-
-Search for features:
-
- - python::pygrass::vector::find
-  - python::pygrass::vector::find::PointFinder
-  - python::pygrass::vector::find::BboxFinder
-  - python::pygrass::vector::find::PolygonFinder
-
-Geometry and topology elements handling:
-
- - python::pygrass::vector::geometry
-  - python::pygrass::vector::geometry::Attrs
-  - python::pygrass::vector::geometry::Geo
-  - python::pygrass::vector::geometry::Point
-  - python::pygrass::vector::geometry::Line
-  - python::pygrass::vector::geometry::Node
-  - python::pygrass::vector::geometry::Boundary
-  - python::pygrass::vector::geometry::Centroid
-  - python::pygrass::vector::geometry::Isle
-  - python::pygrass::vector::geometry::Isles
-  - python::pygrass::vector::geometry::Area
-
-Vector attribute handling:
-
- - python::pygrass::vector::attributes
-
-\subsection pygrassModule Interface to GRASS GIS modules
-
- - python::pygrass::modules
-
-List of high-level classes:
-
- - python::pygrass::modules::interface::module::Module
- - python::pygrass::modules::interface::module::ParallelModuleQueue 
-
-List of namespaces:
-
- - python::pygrass::modules::grid
- - python::pygrass::modules::interface
- - python::pygrass::modules::shortcuts
-
-\subsection pygrassFunctions Functions Package
-
-List of pyGRASS functions:
-
- - python::pygrass::functions
-
-\subsection pygrassMessages Messages Package
-
-Messages handling in PyGRASS:
-
- - python::pygrass::messages::FatalError
- - python::pygrass::messages::Messenger
-
-\subsection pygrassErrors Errors Package
-
-Defined errors classes:
-
- - python::pygrass::errors::ParameterError
- - python::pygrass::errors::FlagError
- - python::pygrass::errors::DBError
- - python::pygrass::errors::GrassError
- - python::pygrass::errors::OpenError
-
-\section pygrassAuthors Authors
-
-Pietro Zambelli (Google Summer of Code 2012)
-
-\section References References
-
-
-*  Zambelli, P., Gebbert, S., Ciolli, M., 2013: *PyGRASS: An Object Oriented Python Application Programming Interface (API) for Geographic Resources Analysis Support System (GRASS) Geographic Information System (GIS)* 
-* . ISPRS International Journal of Geo-Information 2, 201–219. (
-*  `DOI <http://dx.doi.org/10.3390/ijgi2010201>`
-* |
-*  `PDF <http://www.mdpi.com/2220-9964/2/1/201/pdf>`
-* )
-
-*/

Modified: grass/trunk/lib/python/script/Makefile
===================================================================
--- grass/trunk/lib/python/script/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/script/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -2,7 +2,6 @@
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
 DSTDIR = $(ETC)/python/grass/script
 
@@ -26,6 +25,3 @@
 	sed \
 	-e 's#@LD_LIBRARY_PATH_VAR@#$(LD_LIBRARY_PATH_VAR)#' \
 	$< > $@
-
-# doxygen
-DOXNAME = python

Deleted: grass/trunk/lib/python/script/pythonlib.dox
===================================================================
--- grass/trunk/lib/python/script/pythonlib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/script/pythonlib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,264 +0,0 @@
-/*! \page pythonlib GRASS Python Scripting Library
-
-by GRASS Development Team (http://grass.osgeo.org)
-
-\section pythonIntro Introduction
-
-The GRASS Python Scripting Library (<tt>grass.script</tt>) provides
-support for GRASS scripts written in Python programming language. The
-<a href="http://svn.osgeo.org/grass/grass/trunk/scripts">scripts/</a>
-directory of GRASS contains a series of examples actually provided to
-the end users.
-
-- \subpage pythonUsage
-- \subpage pythonModules
- - \subpage pythonCore
- - \subpage pythonUtils
- - \subpage pythonDb
- - \subpage pythonRaster
- - \subpage pythonVector
- - \subpage pythonSetup
- - \subpage pythonArray
-
-\section pythonUsage Usage
-
-The statement
-
-\code
-import grass.script as grass
-\endcode
-
-imports \ref pythonCore, \ref pythonDb, \ref pythonRaster and \ref pythonVector modules.
-
-To import only selected module
-
-\code
-from grass.script import core as grass
-\endcode
-
-Sample script (see the GRASS Wiki at 
-<a href="http://grass.osgeo.org/wiki/GRASS_and_Python">http://grass.osgeo.org/wiki/GRASS_and_Python</a> for more examples)
-
-\code
-#!/usr/bin/env python
-
-#%module
-#% description: Checks if vector map is 3D
-#% keywords: vector
-#%end
-#%option G_OPT_V_MAP
-#%end
-
-import sys
-import grass.script as grass
-
-def main():
-    info = grass.vector_info_topo(map = options['map'])
-    if info['map3d']:
-        print 'Vector map is 3D'
-    else:
-        print 'Vector map is 2D'
-
-    return 0
-
-if __name__ == "__main__":
-    options, flags = grass.parser()
-    sys.exit(main())
-\endcode
-
-\section pythonModules List of functions
-
-\subsection pythonCore Core
-
-<b>GRASS-oriented interface to subprocess module</b>
-
- - python::script::core::exec_command()
-
- - python::script::core::feed_command()
-
- - python::script::core::make_command()
-
- - python::script::core::parse_command()
-
- - python::script::core::pipe_command()
-
- - python::script::core::read_command()
-
- - python::script::core::run_command()
-
- - python::script::core::start_command()
-
- - python::script::core::write_command()
-
-<b>Interface to \gmod{g.message}</b>
-
-These all run \gmod{g.message}, differing only in which flag (if any) is
-used. fatal() is error(), but also calls sys.exit(1).
-
- - python::script::core::debug()
-
- - python::script::core::error()
-
- - python::script::core::fatal()
-
- - python::script::core::info()
-
- - python::script::core::message()
-
- - python::script::core::verbose()
-
- - python::script::core::warning()
-
-<b>Interface to \gmod{g.parser}</b>
-
-Interface to \gmod{g.parser}, intended to be run from the top-level, e.g.
-
-\code
-	if __name__ == "__main__":
-	    options, flags = grass.parser()
-	    main()
-\endcode
-
- - python::script::core::parser()
-
-<b>Interface to \gmod{g.tempfile}</b>
-
-Returns the name of a temporary file, created with \gmod{g.tempfile}.
-
- - python::script::core::tempfile()
-
-<b>Key-value parsers</b>
-
- - python::script::core::parse_key_val()
-
-<b>Interface to \gmod{g.gisenv}</b>
-
- - python::script::core::gisenv()
-
-<b>Interface to \gmod{g.region}</b>
-
- - python::script::core::del_temp_region()
-
- - python::script::core::region()
-
- - python::script::core::region_env()
-
- - python::script::core::use_temp_region()
-
-<b>Interface to \gmod{g.findfile}</b>
-
- - python::script::core::find_file()
-
-<b>Interface to \gmod{g.list}</b>
-
- - python::script::core::list_grouped()
-
- - python::script::core::list_pairs()
-
- - python::script::core::list_strings()
-
-<b>Interface to \gmod{g.mapsets}</b>
-
- - python::script::core::mapsets()
-
-<b>Interface to \gmod{g.version}</b>
-
- - python::script::core::version()
-
-<b>Color parsing</b>
-
- - python::script::core::parse_color()
-
-<b>Check GRASS environment variables</b>
-
- - python::script::core::overwrite()
-
- - python::script::core::verbosity()
-
-<b>Create new GRASS location</b>
-
- - python::script::core::create_location()
-
-<b>Others</b>
-
- - python::script::core::find_program()
-
-\subsection pythonUtils Utils
- 
- - python::script::utils::float_or_dms()
- 
- - python::script::utils::separator()
-
- - python::script::utils::diff_files()
-
- - python::script::utils::try_remove()
-
- - python::script::utils::try_rmdir()
-
- - python::script::utils::basename()
-
- - python::script::utils::parse_key_val()
-
- - python::script::utils::decode()
-
- - python::script::utils::encode()
-
-\subsection pythonDb Database
-
-Interface for <tt>db.*</tt> modules.
-
- - python::script::db::db_connection()
-
- - python::script::db::db_describe()
-
- - python::script::db::db_select()
-
-\subsection pythonRaster Raster
-
-Interface for <tt>r.*</tt> modules.
-
- - python::script::raster::raster_history()
-
- - python::script::raster::raster_info()
-
- - python::script::raster::mapcalc()
-
-\subsection pythonVector Vector
-
-Interface for <tt>v.*</tt> modules.
-
- - python::script::vector::vector_columns()
-
- - python::script::vector::vector_db()
-
- - python::script::vector::vector_db_select()
-
- - python::script::vector::vector_history()
-
- - python::script::vector::vector_info_topo()
-
- - python::script::vector::vector_layer_db()
-
-\subsection pythonSetup Setup
-
-\code
-from grass.script import setup as gsetup
-\endcode
-
- - python::script::setup::init()
-
-\subsection pythonArray Array
-
-\code
-from grass.script import array as garray
-\endcode
-
- - python::script::array::array
-
-\section pythonAuthors Authors
-
- Glynn Clements
-
- Martin Landa <landa.martin gmail.com>
-
-*/

Modified: grass/trunk/lib/python/temporal/Makefile
===================================================================
--- grass/trunk/lib/python/temporal/Makefile	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/temporal/Makefile	2014-09-26 18:57:08 UTC (rev 62097)
@@ -2,7 +2,6 @@
 
 include $(MODULE_TOPDIR)/include/Make/Other.make
 include $(MODULE_TOPDIR)/include/Make/Python.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
 
 PYDIR = $(ETC)/python
 GDIR = $(PYDIR)/grass
@@ -26,6 +25,3 @@
 
 $(DSTDIR)/%: % | $(DSTDIR)
 	$(INSTALL_DATA) $< $@
-
-#doxygen:
-DOXNAME = pythontemporal

Deleted: grass/trunk/lib/python/temporal/pythontemporallib.dox
===================================================================
--- grass/trunk/lib/python/temporal/pythontemporallib.dox	2014-09-26 15:30:56 UTC (rev 62096)
+++ grass/trunk/lib/python/temporal/pythontemporallib.dox	2014-09-26 18:57:08 UTC (rev 62097)
@@ -1,255 +0,0 @@
-/*! \page pythontemporallib GRASS GIS Temporal Framework
-
-by GRASS Development Team (http://grass.osgeo.org)
-
-The GRASS GIS Temporal Framework
-
-\section PythonTGISIntro Introduction
-
-The GRASS GIS Temporal Framework implements the temporal GIS functionality of GRASS GIS
-and provides an API to implement spatio-temporal processing modules. The framework 
-introduces space time datasets that represent time series of raster, 3D raster or vector maps.
-This framework provides the following functionalities: 
-- Assign time stamp to maps and register maps in the temporal database
-- Modification of time stamps
-- Creation, renaming and deletion of space time datasets
-- Registration and un-registration of maps in space time datasets
-- Query of maps that are registered in space time datasets using SQL where statements
-- Analysis of the spatio-temporal topology of space time datasets
-- Sampling of space time datasets
-- Computation of temporal and spatial relationships between registered maps
-- Higher level functions that are shared between modules
-
-Most of the functions described above are member functions of the maps and space time dataset classes.
-Maps and space time datasets are represented as objects in the temporal framework.
-
-\section PythonTGISPackages Library
-
-Core functionality such as the initialization function, the database interface connection to sqlite3 
-and postgresql as well as the creation of the temporal database are defined here:
-
-- python::temporal::core
-
-In these modules are the temporal database interfaces for raster maps, 
-3D raster maps, vector maps and space time datasets defined. 
-In addition the temporal and spatial extent modules implement the topological 
-relationship computation that is needed for spatio-temporal topology computation:
-
-- python::temporal::base
-- python::temporal::spatial_extent
-- python::temporal::temporal_extent
-- python::temporal::metadata
-
-Several "abstract" classes are defined that implement the shared functionality 
-of time stamped maps and space time datasets, such as temporal and spatial
-handling and representation:
-
-- python::temporal::spatial_topology_dataset_connector
-- python::temporal::temporal_topology_dataset_connector
-- python::temporal::abstract_dataset
-- python::temporal::abstract_map_dataset
-- python::temporal::abstract_space_time_dataset
-
-The RPC C-library interface for exit safe and fast access to raster, vector and 3D raster informations:
-
-- python::temporal::c_libraries_interface
-
-All dataset classes that are used in the GRASS temporal modules are specified
-here:
-
-- python::temporal::space_time_datasets
-
-Functions to compute temporal granularity, handling of datetime objects
-and their conversion as well as spatio-temporal topology computation are defined in these modules:
-
-- python::temporal::datetime_math
-- python::temporal::spatio_temporal_relationships
-- python::temporal::temporal_granularity
-
-Functionality that is shared between different temporal GRASS modules, such as
-map listing, space time dataset creation, map registration and unregistration, 
-aggregation, extraction, map calculation, statistics as well as import and export of 
-space time datasets are defined here:
-
-- python::temporal::aggregation
-- python::temporal::extract
-- python::temporal::factory
-- python::temporal::open_stds
-- python::temporal::list_stds
-- python::temporal::mapcalc
-- python::temporal::register
-- python::temporal::sampling
-- python::temporal::stds_export
-- python::temporal::stds_import
-- python::temporal::univar_statistics
-
-Spatio-temporal algebra classes for space time raster and vector datasets are defined in:
-
-- python::temporal::temporal_algebra
-- python::temporal::temporal_vector_algebra
-- python::temporal::temporal_vector_operator
-
-Two helper functions to support the listing of space time datasets in the automatically generated GUI:
-
-- python::temporal::gui_support
-
-Unittests:
-
-- python::temporal::unittests_register
-
-
-\section PythonTGISExamples Examples
-
-\subsection PythonTGISExamplesSimple Simple example
-
-This simple example shows how to open a space time raster dataset
-to access its registered maps.
-
-\code
-# Lets import the temporal framework and
-# the script framework
-import grass.temporal as tgis
-import grass.script as grass
-
-# Make sure the temporal database exists
-# and set the temporal GIS environment
-tgis.init()
-
-# We create the temporal database interface for fast processing
-dbif = tgis.SQLDatabaseInterfaceConnection()
-dbif.connect()
-
-# The id of a space time raster dataset is build from its name and its mapset
-id = "test at PERMANENT"
-
-# We create a space time raster dataset object 
-strds = tgis.SpaceTimeRasterDataset(id)
-
-# Check if the space time raster dataset is in the temporal database
-if strds.is_in_db(dbif=dbif) == False:
-    dbif.close()
-    grass.fatal(_("Space time %s dataset <%s> not found") % (
-        strds.get_new_map_instance(None).get_type(), id))
-
-# Fill the object with the content from the temporal database
-strds.select(dbif=dbif)
-
-# Print informations about the space time raster dataset to stdout
-strds.print_info()
-
-# Get all maps that are registered in the strds and print
-# informations about the maps to stdout
-maps = strds.get_registered_maps_as_objects(dbif=dbif)
-
-# We iterate over the temporal sorted map list
-for map in maps:
-    # We fill the map object with the content 
-    # from the temporal database. We use the existing
-    # database connection, otherwise a new connection 
-    # will be established for each map object 
-    # which slows the processing down
-    map.select(dbif=dbif)
-    map.print_info()
-
-# Close the database connection
-dbif.close()
-\endcode
-
-
-\subsection PythonTGISExamplesSTDSCreation Creation of a space time dataset
-
-This example shows howto create a space time dataset. The code is generic and works
-for different space time datasets (raster, 3D raster and vector): 
-
-\code
-# Lets import the temporal framework and
-# the script framework
-import grass.temporal as tgis
-import grass.script as grass
-
-# The id of the new space time dataset
-id="test at PERMANENT"
-# The title of the new space time dataset
-title="This is a test dataset" 
-# The description of the space time dataset
-description="The description"
-# The type of the space time dataset (strds, str3ds or stvds)
-type="strds"
-# The temporal type of the space time dataset (absolute or relative)
-temporal_type="absolute"
-
-# Make sure the temporal database exists
-# and set the temporal GIS environment
-tgis.init()
-
-# We use the dataset factory to create an new space time dataset instance of a specific type
-stds = tgis.dataset_factory(type, id)
-
-# We need a dtabase connection to insert the content of the space time dataset
-dbif = tgis.SQLDatabaseInterfaceConnection()
-dbif.connect()
-
-# First we check if the dataset is already in the database
-if stds.is_in_db(dbif=dbif) and overwrite == False:
-    dbif.close()
-    grass.fatal(_("Space time %s dataset <%s> is already in the database. "
-                    "Use the overwrite flag.") %
-                (stds.get_new_map_instance(None).get_type(), name))
-
-# We delete the exiting dataset and create a new one in case we are allowed to overwrite it
-if stds.is_in_db(dbif=dbif) and overwrite == True:
-    grass.warning(_("Overwrite space time %s dataset <%s> "
-                    "and unregister all maps.") %
-                (stds.get_new_map_instance(None).get_type(), name))
-    stds.delete(dbif=dbif)
-    stds = stds.get_new_instance(id)
-
-# We set the initial values. This function also created the command history.
-stds.set_initial_values(temporal_type=temporaltype, semantic_type="mean",
-                        title=title, description=description)
-                        
-# Now we can insert the new space time dataset in the database
-stds.insert(dbif=dbif)
-
-# Close the database connection
-dbif.close()
-    
-\endcode
-
-\subsection PythonTGISExamplesShifting Temporal shifting
-
-\code
-
-import grass.script as grass
-import grass.temporal as tgis
-
-id="test at PERMANENT"
-type="strds"
-
-# Make sure the temporal database exists
-tgis.init()
-
-dbif = tgis.SQLDatabaseInterfaceConnection()
-dbif.connect()
-
-stds = tgis.dataset_factory(type, id)
-
-if stds.is_in_db(dbif) == False:
-    dbif.close()
-    grass.fatal(_("Space time dataset <%s> not found in temporal database") % (id))
-
-stds.select(dbif=dbif)
-
-stds.snap(dbif=dbif)
-
-stds.update_command_string(dbif=dbif)
-dbif.close()
-
-\endcode
-
-\section PythonTGISAuthors Authors
-
-Soeren Gebbert
-
-TODO: add more documentation
-*/



More information about the grass-commit mailing list