[GRASS-dev] Re: diff to start wingrass with GUI + com.exe terminal
[was: Re: [winGRASS] (no subject)]
paul-grass at stjohnspoint.co.uk
Mon May 21 16:54:06 EDT 2007
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
(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
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.
More information about the grass-dev