Make GUI toolboxes mechanism independent on wxGUI

[wenzeslaus]

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.

[wenzeslaus]

Currently, there are two tickets which depends on this one: #645 (#762) and #1203.

[wenzeslaus]

The compilation issues should be reduced by r64677 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 (#645, #1203). Relation to addons is yet to be determined.

[neteler]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.4 milestone.

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed