[GRASS-dev] Re: a better console and better diff

[Michael Barton]

On Dec 16, 2009, at 4:22 AM, Martin Landa wrote:

> Hi,
> 
> 2009/12/11 Michael Barton <michael.barton at asu.edu>:
> 
>> --Type a grass command. When you get to the ".", it brings up an
>> autocomplete list of relevant commands. Keep typing (or mouse up/down) until
>> you find the one you want and hit return.
>> 
>> --Press <tab> to see full calltips of command syntax for each command
>> entered (one command per line please)
>> 
>> --As you type the command arguments, hitting "=" and "," following an
>> "=[string]" combination will bring up context-sensitive lists of relevant
>> maps or other data sets (e.g. regions where appropriate).
>> 
>> --You can type ctrl-space to bring up a context sensitive list of maps for
>> raster, vector, etc. at any place in the command.
>> 
>> --Pressing return on the command line will run it.
>> 
>> This will accept shell commands (redirects and pipes don't work but could),
>> grass commands without arguments (brings up the GUI dialogs), and grass
>> commands with the short form arguments (r.info mymap) as well as full grass
>> commands with argument=value format.
> 
> Most of the things are already implemented in GPrompt! Better would be
> to make working GPrompt class on Mac.
> 
> Martin

Hi Martin,

GPrompt won't work on the Mac because it uses a the PopupWindow control that does not exist for Mac. To make it work, it would be necessary to custom code an equivalent popup window. 

If we use the separate command entry window interface, I think the better way to go is to change it to a StyledTextCtrl. This was a very good idea of yours to make the output window a StyledTextCtrl. 

If the input window is changed to a STC, then we can make use of its built-in autocomplete and calltip functions. I realize that you did a lot of coding to create a custom autocomplete in GPrompt, but I think we are ultimately better off to use wxPython built-in functions as much as possible when they are available. They are often more robust over time and easier for another person to understand--and others than you and I may well need to debug and maintain this in the future. I've seen a lot of old custom widget code for the TclTk GUI and it is very difficult to deal with. If we create a custom popup that works on Mac, we add even more custom code for an autocomplete feature.

In this case, the STC autocomplete and calltip functions work very well and we only need to create the relevant lists of informatoin (commands, maps, etc) that go into them and the specify the keystrokes that call them.  I've done that and we can make use of and enhance that code (e.g., change the keystrokes if desired). We don't need to code list controls, the ability to type and search, popup windows, getting the list into the popup, and the proper placement of the windows.

I personally don't mind separate input and output windows. Many people who use terminals are accustomed to having input and output in the same window, and using the STC, it is minimal effort to have this kind of interface. But maybe command line users like the idea of separate input and output windows.  We probably can also visually merge the 2 windows so that the input acts more like a command line prompt that never scrolls up. I guess I'd recommend whichever way terminal users are most comfortable with in this regard.

Michael