Make GUI toolboxes mechanism independent on wxGUI

[landam]

Reported by wenzeslaus on 13 Dec 2013 20:35 UTC All the main parts of GUI toolboxes mechanism should be independent on wxGUI to enable smooth usage at all occasions.

Python module or package to generate and to work with GUI toolbox files (in theory) does not need anything GUI-related, thus it does not need wxGUI. Making the toolboxes module/package independent on wxGUI makes it independent on wxPython, so as a consequence it would be possible to use toolboxes module/package without wxPython. This would enable usage of toolboxes module/package by other software which uses GRASS without wxGUI (and possibly does not have wxPython). Moreover, it would decrease the requirements on environment during compilation (which now requires wxPython to be ready to use), so toolboxes module/package would be more reliable when used during compilation.

Note that this would fix the cases when toolboxes are not compiled because of wrong linking to wxWidgets or wxPython during compilation (observed on Mac OS X and on some particular Linux system configurations). Note also that it is unclear what is causing errors related to toolboxes compilation and that it seems that the real problem is in Makefiles because when compiling inside GRASS session toolboxes compilation work.

Toolboxes module depends on:

from core.globalvar import ETCWXDIR
from core.utils import GetSettingsPath, _
from core.gcmd import GError, RunCommand
from core.debug import Debug

ETCWXDIR is simple and can be either defined in lib/python/ (grass package) or redefined in toolboxes module.

ETCWXDIR = os.path.join(ETCDIR, "gui", "wxpython")

GetSettingsPath is more complex it is would be better to not repeat it again. Maybe, moving to lib/python/ (grass package) is the right option if there is some usage of this function for GRASS modules in general.

def GetSettingsPath():
    """!Get full path to the settings directory
    """
    try:
        verFd = open(os.path.join(ETCDIR, "VERSIONNUMBER"))
        version = int(verFd.readlines()[0].split(' ')[0].split('.')[0])
    except (IOError, ValueError, TypeError, IndexError), e:
        sys.exit(_("ERROR: Unable to determine GRASS version. Details: %s") % e)

    verFd.close()

    # keep location of settings files rc and wx in sync with lib/init/grass.py
    if sys.platform == 'win32':
        return os.path.join(os.getenv('APPDATA'), 'GRASS%d' % version)

    return os.path.join(os.getenv('HOME'), '.grass%d' % version)

The underscore function might be defined again or moved from utils to separate translations module. (Site note: translation function must be handled carefully in toolboxes because of potential multiple sources for of translation strings in future.)

try:
    # intended to be used also outside this module
    import gettext
    _ = gettext.translation('grasswxpy', os.path.join(os.getenv("GISBASE"), 'locale')).ugettext
except IOError:
    # using no translation silently
    def null_gettext(string):
        return string
    _ = null_gettext

GError class (why class, btw?) usages in toolboxes module should be replaced by other error mechanism, probably exceptions because only those are independent enough.

RunCommand function is just yet another wrapper (wxGUI friendly in this case) to grass.script.core.start_command and can be probably replaced by some new wrapper which raises exception on error.

Debug can be easily replaced by grass.script.core.debug or grass.pygrass.messages.Messenger. The only problem is the change from wxGUI WXDEBUG variable to GRASS standard DEBUG variable.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/2142

[landam]

Comment by wenzeslaus on 29 Mar 2014 02:29 UTC Currently, there are two tickets which depends on this one: #27 (https://trac.osgeo.org/grass/ticket/762) and https://trac.osgeo.org/grass/ticket/1203.

[landam]

Comment by wenzeslaus on 18 Feb 2015 04:23 UTC The compilation issues should be reduced by https://trac.osgeo.org/grass/changeset/64677 which uses wxGUI (and wx) only when really necessary and can deal with errors during import of wx dependent things.

Next step should be moving toolboxes to to the library, e.g. grass.tools.toolboxes or grass.utils.toolboxes. Then creating a separate module, e.g. g.toolboxes. GUI and the module would depend on the library. Tests can be written against library or module. GUI testing can be reduced by parametrization of functions which read from user settings by having some override directory parameter in the library. Library is better than module for GUI because functions to build (in memory) XML are needed when loading addons and "runtime modules" (modules which were not loaded during compilation but are loaded during start). Compilation would use the module. This module, or some other module, would implement things related to the manual (#27, https://trac.osgeo.org/grass/ticket/1203). Relation to addons is yet to be determined.

[landam]

Modified by neteler on 24 Nov 2015 08:10 UTC

[landam]

Comment by neteler on 5 May 2016 14:08 UTC Milestone renamed

[landam]

Comment by neteler on 28 Dec 2016 15:04 UTC Ticket retargeted after milestone closed

[landam]

Modified by @landam on 5 May 2017 20:41 UTC

[landam]

Comment by @landam on 1 Sep 2017 20:28 UTC All enhancement tickets should be assigned to 7.4 milestone.

[landam]

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

[landam]

Modified by neteler on 12 Jun 2018 20:48 UTC

[landam]

Comment by @landam on 25 Sep 2018 16:53 UTC All enhancement tickets should be assigned to 7.6 milestone.

[landam]

Comment by @landam on 25 Jan 2019 21:08 UTC Ticket retargeted after milestone closed