Opened 11 years ago

Closed 10 years ago

#234 closed defect (duplicate)

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

Reported by: msieczka Owned by: martinl
Priority: major Milestone: 6.4.0
Component: wxGUI Version: svn-develbranch6
Keywords: wingrass Cc: grass-dev@…
CPU: All Platform: MSWindows XP

Description

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

Change History (15)

comment:1 in reply to:  description Changed 11 years ago by 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.

comment:2 Changed 11 years ago by martinl

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

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?

comment:3 Changed 11 years ago by 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

comment:4 in reply to:  2 ; Changed 11 years ago by 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.

comment:5 in reply to:  4 Changed 11 years ago by 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).

comment:6 Changed 11 years ago by cmbarton

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

comment:7 in reply to:  6 Changed 11 years ago by 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

comment:8 Changed 11 years ago by 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'.

comment:9 Changed 11 years ago by hamish

see also bug #580

comment:10 Changed 11 years ago by hamish

Keywords: wingrass added
Platform: AllMSWindows XP

comment:11 Changed 11 years ago by 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

comment:12 Changed 11 years ago by 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

comment:13 Changed 10 years ago by 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

comment:14 Changed 10 years ago by 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

comment:15 Changed 10 years ago by hamish

Resolution: duplicate
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.