v.type, v.type.sh, GUI and WinGRASS

[msieczka]

Autogenerated v.type wxGUI still suffers from an old bug described on [1]. The v.type.sh workaround will not work on Windows without msys. Would a Python replacement do? Or is it possible to fix the problem instead of a workaround?

Cedric Shock describes the issue in detail:

The options type is interpreted by the gui as being a set of boolean values (thus the checkboxes). This is how it's used in many other modules, such as d.vect.

v.type assumes a different semantic meaning to options (a type safe enumerated list) and relies heavily on the behaviour of the options implementation for error safety and parsing (I have no quick fix).

There is probably a hack fix like the following: declare the parser.c option of v.type to be a regular text (not option) option. After parser.c has handed back the options structure hand jsut this option (possibly with its type modified) back to whatever parser.c "function" parses the list of options as-is. The correct fix is to either add another semantic meaning to the parser system for a type safe enumerated list or to copy the code that does this into v.type.

[1]​https://www.intevation.de/rt/webrt?serial_num=296

[glynn]

Replying to msieczka:

Autogenerated v.type wxGUI still suffers from an old bug described on [1]. The v.type.sh workaround will not work on Windows without msys. Would a Python replacement do?

Yes (assuming that you have python).

Alternatively, we could hack v.type to omit the various ->options fields if argv[1] is --ui, --tcltk or --interface-description.

Or is it possible to fix the problem instead of a workaround?

Modifying the way that the GUI handles the case where opt->multiple is true and opt->options is set is possible, but it would be inconvenient for the other modules which don't care about order (i.e. where the value is a set instead of a list).

To support both sets and lists, we would need to extend the semantics of the Option structure, extend the parser, and extend both GUIs.

[martinl]

I replaced v.type.sh by v.type.py (r33023, r33025 in devbr6, and r33024, r33026 in trunk). I also removed v.type.sh in trunk (r33027), can we remove it also in devbr6?

[cmbarton]

We may need to retain v.type.sh in develbranch_6 for backward compatibility, command line use without Python (not a dependency for GRASS 6), and for TclTk.

Michael

[glynn]

Replying to martinl:

I replaced v.type.sh by v.type.py (r33023, r33025 in devbr6, and r33024, r33026 in trunk). I also removed v.type.sh in trunk (r33027), can we remove it also in devbr6?

Python isn't supposed to be a mandatory dependency in 6.x.

[martinl]

Replying to glynn:

I replaced v.type.sh by v.type.py (r33023, r33025 in devbr6, and r33024, r33026 in trunk). I also removed v.type.sh in trunk (r33027), can we remove it also in devbr6?

Python isn't supposed to be a mandatory dependency in 6.x.

Sorry, I have reverted changes in menudata to use v.type.sh (r33034, r33035).

[cmbarton]

Why can't we use v.type.sh for TclTk and v.type.py for wxPython?

[martinl]

Replying to cmbarton:

Why can't we use v.type.sh for TclTk and v.type.py for wxPython?

v.type.py is already used in wxPython GUI, see

cat gui/wxpython/xml/menudata.xml | grep -n 'v.type'
1501:         <command>v.type.py</command>

Martin

[cnielsen]

This bug still does not seem to be resolved, I get the following error from my mingw/msys from trunk and from develbranch_6:

trunk: Traceback (most recent call last):

File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m

odules\mapdisp_window.py", line 536, in OnIdle

self.UpdateMap(render=True)

File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m

odules\mapdisp_window.py", line 661, in UpdateMap

self.Draw(self.pdc, self.img, drawid=id)

File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m

odules\mapdisp_window.py", line 289, in Draw

pdc.DrawBitmap(bitmap, wx.Point(coords[0], coords[1]), True) # draw the composite map

File "c:\MinGW\Python\lib\site-packages\wx-2.8-msw-

unicode\wx\_gdi.py", line 7438, in DrawBitmap

return _gdi_.PseudoDC_DrawBitmap(*args, kwargs) TypeError : in method 'PseudoDC_DrawBitmap', expected argument 3 of type 'int' Traceback (most recent call last):

File

"C:/MinGW/msys/local/grass-7.0.svn/etc/wxpython/wxgui.py", line 521, in OnMenuCmd

menuform.GUI().ParseCommand(cmd, parentframe=self)

File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m

odules\menuform.py", line 1732, in ParseCommand

xml.sax.parseString( getInterfaceDescription(cmd[0]), handler )

File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m

odules\menuform.py", line 1673, in getInterfaceDescription

raise IOError, _("Unable to fetch interface description for command '%s'.") % cmd IOError : Unable to fetch interface description for command 'v.type.py'.

develbranch_6:

Traceback (most recent call last):

File

"C:/MinGW/msys/local/grass-6.4.0svn/etc/wxpython/wxgui.py", line 514, in OnMenuCmd

menuform.GUI().ParseCommand(cmd, parentframe=self)

File "C:\MinGW\msys\local\grass-6.4.0svn\etc\wxpython\gui_

modules\menuform.py", line 1711, in ParseCommand

xml.sax.parseString( getInterfaceDescription(cmd[0]), handler )

File "C:\MinGW\msys\local\grass-6.4.0svn\etc\wxpython\gui_

modules\menuform.py", line 1652, in getInterfaceDescription

raise IOError, _("Unable to fetch interface description for command '%s'.") % cmd IOError : Unable to fetch interface description for command 'v.type.py'.

[hamish]

see also bug #580

[hamish]

original bug cite for this ticket had a typo, the correct URL is ​http://www.intevation.de/rt/webrt?serial_num=2969

I may have solved the problem of v.type[.sh|.py] not running on WinGRASS with r37085, 86, 87. The scripts in gui/scripts/ were missing .bat wrappers. leaving bug open as I haven't properly tested it.

Hamish

[hamish]

Hi,

For the wxPython GUI I think there needs to be a new self.OnHelperCmd handler defined for .py wrapper scripts that live in $GISBASE/etc/gui/scripts/.

It would be essentially the same as self.OnRunCmd but it would add os.getenv("GISBASE")/etc/gui/scipts/ to the command name.

right now it can't find them; and that dir doesn't really need to be in the PATH.

specifically this is for v.type_wrapper.py and g.change.gui.py. (vector -> develop -> change; config -> environ -> default GUI)

?, Hamish

[cmbarton]

Is v.type.py now running in Windows? Can this ticket be closed?

The last message in this ticket ("For the wxPython GUI I think there needs to be a new self.OnHelperCmd? handler defined for .py wrapper scripts that live in $GISBASE/etc/gui/scripts/...") seems to be a somewhat different (though related) issue and should perhaps have its own ticket. I don't quite understand what is being requested, but can work with someone on it if it is still relevant.

Michael

[hamish]

Is v.type.py now running in Windows?

Nope. (now renamed v.type_wrapper.py to avoid name conflict after .py is removed by wingrass makefile)

Can this ticket be closed?

Nope. The fix/workaround isn't working yet.

... seems to be a somewhat different (though related) issue and should perhaps have its own ticket.

I'm pretty sure it does, see wingrass bug #580. (report:13)

Hamish

[hamish]

closing this as a dupe of #580.

the original report mentions that .sh won't work with out MSys, but 10% of our 6.4 modules need MSys anyway, and for grass 7 there are already .py versions written for v.type_wrapper and g.change.gui.

Hamish