Markus Metz wrote: > > All of this goes out the window if you want to provide a command-line > > environment, whether an interactive shell or the ability to execute > > commands via system() or CreateProcess(). > > It works in GRASS 6 with shell scripts. I am sure the same mechanism > will work just as well with python scripts.
GRASS 6 creates a .bat file for each shell script. > > The only way that you can "configure" Windows' command execution > > mechanism is by registering extensions. > > I suggest to not even attempt to configure a Windows' command > execution mechanism. If you mean "don't mess with the existing .py association", I agree with you. If you mean "make every attempt to bypass the standard execution mechanisms", that will make WinGRASS a second-rate imitation of the Unix version. In spite of wxGUI, GRASS remains fundamentally a collection of command-line modules, more like a library than an application. The big advantage of this is that that it can be scripted, in any language capable of executing commands. Python, Bourne Shell, cmd.exe, Visual Basic, or whatever. You can either attempt to "capture" and bypass as many of the possible interfaces to the system's execution mechanism as possible, or you can make the system's execution mechanism work. The latter one requires dealing with factors beyond our control, but ultimately it results in a superior product (it's also less work). > >> Instead of battling the MS Windows software management system, > > > > But that's exactly what trying to "bundle" Python is doing. You don't > > trust the OS to be configured correctly so you're trying to construct > > an isolated sandbox. > > Exactly! E.g. LibreOffice and Gimp also operate as isolated sandboxes. > Actually, pretty much every MS Windows software is an isolated > sandbox. This is the safest way to ensure proper operation on MS > Windows. These are self-contained GUI applications. Which is a major limitation; if I need to manipulate images, I'm more likely to use NetPBM or PIL/NumPy than GIMP (on any platform). Apart from anything else, the job will be over and done while GIMP would still be showing the splash screen. If I'm likely to perform the same operation more than once, I'm *much* more likely to use the scripted approach than the pointy-clicky GUI. > IMHO, what you say is that GRASS and MS Windows are incompatible by > principle, Not at all. Windows does actually have a command-execution mechanism (even the Mac has one nowadays). Some people even run web servers on Windows (and I don't believe that Microsoft has yet found a way to use arbitrary GUI programs in place of PHP, ASP or whatever). > and you will not succeed in making MS Windows compatible > with these GRASS principles. I assume WinGRASS users expect a typical > MS Windows software like clicking on the GRASS icon which executes a > command (grassXY) and starts the software. I strongly suggest to > respect the users' expectations. It does not matter in this respect if > the command actually only sets the environment for GRASS modules and > if this environment is like a sandbox or system-wide. FWIW, Linux > users also execute a grassxy command to start GRASS. No matter how much GUI you wrap around it, GRASS is never going to be a "point-and-drool" application aimed at users who want a "Solve my problem for me" icon on the toolbar. I would expect anything beyond the simplest cases to be scripted. So that you can easily repeat the exact process with next month's data, or with a different value for a parameter, or so that you can easily communicate your methodology to others (I find pasting a script fragment somewhat easier than "... then click on the icon that looks like, uh, ..."). -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev