[GRASS-dev] Re: diff to start wingrass with GUI + com.exe terminal [was: Re: [winGRASS] (no subject)]

[Paul Kelly]

On Mon, 21 May 2007, Hamish wrote:

>> Was thinking perhaps an option button in gis_set.tcl (the first Tcl/Tk
>> window that allows you to select the location) to open either GUI or
>> Command-line Windows or both might be a nice idea?
>
> How about a menu item to open a terminal in the main File-> or Config->
> menus? Or a button on the GIS Manager toolbar? (of course "-text" on
> startup would get you there without the GUI as well)

I think that is more complicated than it needs to be. The GUI needs to 
know what the user's preferred terminal emulator is and have separate code 
for Unix and Windows etc. I was thinking perhaps a tick box in gis_set.tcl 
to say either "GUI only" or "GUI + command-line Window" could influence 
the return value gis_set.tcl returns to Init.sh. Then it could decided 
whether to either
(1) spawn gis.m in the background and to open an interactive GRASS 
prompt, or
(2) to just launch gis.m and block while waiting for the user to 
exit using File-->Exit
(1) is what Init.sh currently does, (2) is what init.bat currently does. 
Would be nice if both of them had the choice. It would just be one extra 
checkbox to be added to gis_set.tcl. Might be a nice hint (especially to 
Windows users) too that there is a more powerful command line interface 
available, to tempt them after they get comfortable with the GUI.

And if a user wants only command-line and no GUI there is still
"grass63 -text" for that, which avoids gis_set.tcl. And works with both 
Init.sh and init.bat.

>> I was going by the thinking that it was a historical accident that GUI
>> and command-line were available at the same time with Init.sh, and
>> with improvements to the GUI it would eventually incorporate a sort
>> of command-line interface (like an improved gronsole.tcl) and a
>> separate command-line Window wouldn't be necessary, but if we feel
>> that it's good  to have it there to emphasis the power of GRASS then
>> we can definitely put it into init.bat too.
>
> As you hint to, support is already (sort of) there in a non-obvious way
> from gronsole.tcl, just type any shell command in the bottom part of the
> "Output - GIS.m" window and click [Run]. Maybe it just needs some
> tidying and a GRASS> prompt or something? Or is that always going to
> suck badly versus a true <xterm|cmd.exe> window?

I think it would go some way towards making it adequate and might be 
enough for some users. My expectations of this are somewhat more modest 
than the lists Maciek and Moritz have proposed. Indeed history is already 
there - unfortunately commands already run are only selectable by 
scrolling back up and clicking with the mouse - perhaps it might be not 
much work to make the up arrow button also function for scrolling back 
through commands.

Redirection to a file is important for me too, rather than having to drag 
and copy and paste off the gronsole screen. Again, this might not be too 
hard to implement through Tcl because there is support there in the 
program launching commands to redirect stdout and stderr. And presumably 
this sort of thing is even easier with Python.

Also I wonder could it not be made that pressing Enter runs the currently 
highlighted command. Pressing enter currently brings you on to a new line 
in the text box which doesn't make sense to me?

> Does this start to violate concurrent mapset use?

I don't think so - commands run from the menus and icons in the GUI show 
up in the gronsole.tcl Window the same way as commands run directly from 
the bottom panel so I don't think it's possible to run them concurrently.

Paul