[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter:  hamish        |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  blocker       |   Milestone:  6.4.0                    
 Component:  wxGUI         |     Version:  6.4.0 RCs                
Resolution:                |    Keywords:  wingrass                 
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------
Comment (by hamish):

 Replying to [comment:24 cmbarton]:
 > maybe this is better done by a small, quick method inside the
 > GUI code. It should work for all platforms that way.

 while that may work for expediency, the best solution is to actually
 tackle the bug, figure it out, and solve the general case as it will cause
 more problems once we are more dependent on python scripts in MS Windows.


 > >  * v.type from a GUI is impossible and needs a wrapper.
 >
 > Yes. This needs a script. Or v.type needs to be rewritten a
 > little so that it parses intelligently.

 the problem is due to the limitations of G_parser() and the module GUI
 generation code, not specifically v.type. Personally I think it is counter
 productive to force the modules to work around those limitations, as
 opposed to addressing the fundamental problem. (the same goes for forcing
 module options into the Required tab which don't really need to be there,
 just for the exposure)

 I'm not sure how well v.clean will work from the GUI launchers.

 this is something to work on in trunk of course, not 6.x. in 6 we have to
 rely on these wrapper scripts..


 > > > A regular Python installation will properly put Python in
 > > > the registry so that it can be called to execute scripts.
 > >
 > > we ''should'' have the equivalent already set up in the
 > > msinstaller startup batch files and scripts to associate .py
 > > with a suitable python.exe.  check this bug's previous comments
 > > & grep the msinstaller scripts for more.  but that isn't
 > > working for some reason.
 >
 > IIRC, Glynn said that it is necessary to alter the Windows
 > registry for it to work.

 see comment:4,5 above. We can do that automatically from a dos batch file.

 > That is why doing a regular Python installation is preferable.

 we need to check the registry and set something if not already set. if
 already set we should not stomp on what the user has already set up. This
 doesn't require our own python, just something that works and is >2.4 or
 so. The wx + C++ modules on the other hand are the trickier problem.

 > Currently, no Python script works.

 :-(

 note that there are shell versions of those two scripts in the same dir
 which are used by gis.m. Perhaps we can use those and delay dealing with
 the .py problem until the next release.. they should work like any other
 of the shell script modules in 6.x, just in a slightly different dir. They
 could be installed into the main shell script dir as an ugly work around.


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:25>
GRASS GIS <http://grass.osgeo.org>