g.mapsets access from menu broken

[cmbarton]

Trying to access g.mapsets from the menu raises the following error:

Traceback (most recent call last):

File "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc

/gui/wxpython/wxgui.py", line 304, in OnMapsets

dlg = preferences.MapsetAccess(parent = self, id = wx.ID_ANY)

File "/Users/cmbarton/grass_dev/grass70_dev/dist.i386

-apple- darwin10.5.0/etc/gui/wxpython/gui_modules/preferences.py", line 2183, in init

wx.Dialog.init(self, parent, id, title, pos, size, style) NameError : global name 'pos' is not defined

[cmbarton]

Turns out that g.mapsets cannot be launched from the command line or terminal either. No way to set mapset access in GRASS 7 currently. Changing component from wxGUI to ... hmmm there is no component for general, configuration, or settings. I'm picking "installation" because this is slightly less erroneous than the other choices.

Michael

[martinl]

Replying to cmbarton:

Turns out that g.mapsets cannot be launched from the command line or terminal either. No way to

g.mapsets doesn't start from the cli because all parameters are optional. Probably we could change this behaviour in GRASS7. You can force launching GUI dialog by

g.mapsets --ui

set mapset access in GRASS 7 currently. Changing component from wxGUI to ... hmmm there is no component for general, configuration, or settings. I'm picking "installation" because this is slightly less erroneous than the other choices.

fixed in r44412.

Martin

[glynn]

Replying to martinl:

g.mapsets doesn't start from the cli because all parameters are optional. Probably we could change this behaviour in GRASS7.

Note that GRASS 7 intentionally doesn't launch a GUI when all required parameters are provided. In 6.x, modules which want to be able to run without parameters must skip the call to G_parser() if no parameters are given. The problem here is that G_parser() performs some necessary tasks even when no options are provided, so it should always be called.

The real problem is that "required" options have to be marked as optional if there are any special cases which eliminate the requirement, e.g. the "-l" flag in the case of g.mapsets. Ideally, we should add a mechanism to allow such flags to suppress the checking of required options, so that the ->required field can be set based upon normal usage rather than a worst-case scenario.

[glynn]

Replying to glynn:

The real problem is that "required" options have to be marked as optional if there are any special cases which eliminate the requirement, e.g. the "-l" flag in the case of g.mapsets.

My mistake; g.mapsets really doesn't have any required options. If it does nothing when no options are given, it should probably at least generate an error along the lines of "at least one of ... must be given".

[martinl]

Replying to glynn:

The real problem is that "required" options have to be marked as optional if there are any special cases which eliminate the requirement, e.g. the "-l" flag in the case of g.mapsets.

My mistake; g.mapsets really doesn't have any required options. If it does nothing when no options are given, it should probably at least generate an error along the lines of "at least one of ... must be given".

in the case that GRASS_GUI is not 'text' better to launch GUI dialog.

[cmbarton]

So the menu entry in the GUI should be "g.mapsets --ui" rather than g.mapsets?

[martinl]

Replying to cmbarton:

So the menu entry in the GUI should be "g.mapsets --ui" rather than g.mapsets?

No, from wxGUI it will run without -ui. I was speaking about CLI.