[GRASS-dev] a better console and better diff

[cmbarton]

First, thanks to all who advised me on making a diff that actually patches correctly (I hope).

Here is a console with full autocomplete and calltips. For GRASS 6.5

I've put it on auto to show how it can work, but the autocompletion could move to control key combinations too.

--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.

****IMPORTANT WARNING***** Turn OFF the preferences/configuration for default raster color tables. This is causing a bug to affect any command entered from this console or the existing command prompt.

(attachments)

console_example4.patch (15.3 KB)
goutput.py (42.8 KB)
wxgui.py (62.1 KB)

[cmbarton]

A quick note. I forgot to mention that there is also command history as before. Press ctrl-up or ctrl-down.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 10, 2009, at 5:51 PM, Michael Barton wrote:

First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).

Here is a console with full autocomplete and calltips. For GRASS 6.5

I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.

--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.

****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.

<console_example4.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

[cmbarton]

For those that ask, here is a set of screenshots showing using the proposed terminal to enter a simple grass command. Hard to capture the actual action, but perhaps this series 1-4 conveys it.

http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg

Michael

On Dec 10, 2009, at 6:54 PM, Michael Barton wrote:

A quick note. I forgot to mention that there is also command history
as before. Press ctrl-up or ctrl-down.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 10, 2009, at 5:51 PM, Michael Barton wrote:

First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).

Here is a console with full autocomplete and calltips. For GRASS 6.5

I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.

--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.

****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.

<
console_example4
.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

[Tim_Michelsen]

Michael Barton schrieb:

For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.

http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg

Michael

Great.
Will this go into the offical code?

[Dylan_Beaudette]

On Friday 11 December 2009, Michael Barton wrote:

For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.

http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg

Michael

On Dec 10, 2009, at 6:54 PM, Michael Barton wrote:
> A quick note. I forgot to mention that there is also command history
> as before. Press ctrl-up or ctrl-down.
>
> Michael
> ____________________
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> Phone: 480-965-6262
> Fax: 480-965-7671
> www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
> On Dec 10, 2009, at 5:51 PM, Michael Barton wrote:
>> First, thanks to all who advised me on making a diff that actually
>> patches correctly (I hope).
>>
>> Here is a console with full autocomplete and calltips. For GRASS 6.5
>>
>> I've put it on auto to show how it can work, but the autocompletion
>> could move to control key combinations too.
>>
>>
>> --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.
>>
>> ****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
>> default raster color tables. This is causing a bug to affect any
>> command entered from this console or the existing command prompt.
>>
>> <
>> console_example4
>> .patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

Hi Michael,

I applied the patch, and it almost works. After running a command, I am not
presented with a new line-- I need to erase the last command in order to
enter a new one.

Also, there is about a 45 second delay between a d.rast command and output on
the canvas... Do you know what could be causing this?

Finally, after about 30 seconds I received a warning that d.erase wasn't yet
supported.

I like the idea here, but the speed of rendering is far too slow for standard
usage.

Cheers,
Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[cmbarton]

Hi Dylan,

Thanks very much for trying this out. A few responses below.

On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:

Hi Michael,

I applied the patch, and it almost works. After running a command, I am not
presented with a new line-- I need to erase the last command in order to
enter a new one.

This seemed weird so I tried it out. This only happens with d.* commands. I don't know why, but am sure that it is fixable.

Also, there is about a 45 second delay between a d.rast command and output on
the canvas... Do you know what could be causing this?

Mine shows up in a second or two. I'm not sure what is causing this but can speculate a little. First, have you turned on the 'constrain display resolution to computational region settings' in the preferences? If so, and if you have a map with a lot of cells, this will render slowly because d.rast has to write out a file with that many pixels, then on the fly compress them into the size that fits into your screen window. This would be the case with any image renderer. The default is to turn this off and have intelligent rendering, where the graphic file rendered by d.rast is sized to match the display window in advance. So it writes comparatively few pixels. For most purposes, GRASS should stay in this mode because you can only see the number of pixels in your display window, regardless of the number of cells in your map.

If you do not have the 'constrain display resolution..' mode set this way, I'm don't know what the problem is. Even very large maps display quite quickly for me--in a couple seconds at the most. Could be you are out of disk space or RAM???

Finally, after about 30 seconds I received a warning that d.erase wasn't yet
supported.

This may be related to the slow rendering issue. I get the message that d.erase is not implemented immediately. Note that d.erase should be easy to implement.

I like the idea here, but the speed of rendering is far too slow for standard
usage.

Clearly this is far too slow, but the rendering speed (or rather its lack) is not a function of either the console or wxPython canvas in this case. Is it that slow when you display from the layer manager too?

Have you tried it for other commands -- all the non display commands? Other shell commands? Any thoughts?

Michael

[Dylan_Beaudette]

On Tuesday 15 December 2009, Michael Barton wrote:

Hi Dylan,

Thanks very much for trying this out. A few responses below.

On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:
> Hi Michael,
>
> I applied the patch, and it almost works. After running a command, I am
> not presented with a new line-- I need to erase the last command in order
> to enter a new one.

This seemed weird so I tried it out. This only happens with d.* commands. I
don't know why, but am sure that it is fixable.

Hi,

OK. I'll wait and see how things develop with the d.* commands. Overall, I
really like the idea, and command-completion is a real time saver!

> Also, there is about a 45 second delay between a d.rast command and
> output on the canvas... Do you know what could be causing this?

Mine shows up in a second or two. I'm not sure what is causing this but can
speculate a little. First, have you turned on the 'constrain display
resolution to computational region settings' in the preferences? If so, and
if you have a map with a lot of cells, this will render slowly because
d.rast has to write out a file with that many pixels, then on the fly
compress them into the size that fits into your screen window. This would
be the case with any image renderer. The default is to turn this off and
have intelligent rendering, where the graphic file rendered by d.rast is
sized to match the display window in advance. So it writes comparatively
few pixels. For most purposes, GRASS should stay in this mode because you
can only see the number of pixels in your display window, regardless of the
number of cells in your map.

I checked, and the 'constrain display resolution to computational region
settings' box was un-checked. I am working with the default Spearfish region,
so this really isn't all that many cells.

If you do not have the 'constrain display resolution..' mode set this way,
I'm don't know what the problem is. Even very large maps display quite
quickly for me--in a couple seconds at the most. Could be you are out of
disk space or RAM???

3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...

> Finally, after about 30 seconds I received a warning that d.erase wasn't
> yet supported.

This may be related to the slow rendering issue. I get the message that
d.erase is not implemented immediately. Note that d.erase should be easy to
implement.

> I like the idea here, but the speed of rendering is far too slow for
> standard usage.

Clearly this is far too slow, but the rendering speed (or rather its lack)
is not a function of either the console or wxPython canvas in this case. Is
it that slow when you display from the layer manager too?

Have you tried it for other commands -- all the non display commands? Other
shell commands? Any thoughts?

All commands seem to have a delay-- even executing g.region causes the CPU to
jump to 100% for about 15 seconds.

Cheers,
Dylan

Michael

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[cmbarton]

What is your OS?

Something is very squirrelly. I'm also looking at spearfish. All displays should be in a second or two; commands like r.info should be instantaneous. I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo. So it's not as hot as your machine.

Do you have any other strange issues/messages with the GUI or Python?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:

On Tuesday 15 December 2009, Michael Barton wrote:

Hi Dylan,

Thanks very much for trying this out. A few responses below.

On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:

Hi Michael,

I applied the patch, and it almost works. After running a command, I am
not presented with a new line-- I need to erase the last command in order
to enter a new one.

This seemed weird so I tried it out. This only happens with d.* commands. I
don't know why, but am sure that it is fixable.

Hi,

OK. I'll wait and see how things develop with the d.* commands. Overall, I
really like the idea, and command-completion is a real time saver!

Also, there is about a 45 second delay between a d.rast command and
output on the canvas... Do you know what could be causing this?

Mine shows up in a second or two. I'm not sure what is causing this but can
speculate a little. First, have you turned on the 'constrain display
resolution to computational region settings' in the preferences? If so, and
if you have a map with a lot of cells, this will render slowly because
d.rast has to write out a file with that many pixels, then on the fly
compress them into the size that fits into your screen window. This would
be the case with any image renderer. The default is to turn this off and
have intelligent rendering, where the graphic file rendered by d.rast is
sized to match the display window in advance. So it writes comparatively
few pixels. For most purposes, GRASS should stay in this mode because you
can only see the number of pixels in your display window, regardless of the
number of cells in your map.

I checked, and the 'constrain display resolution to computational region
settings' box was un-checked. I am working with the default Spearfish region,
so this really isn't all that many cells.

If you do not have the 'constrain display resolution..' mode set this way,
I'm don't know what the problem is. Even very large maps display quite
quickly for me--in a couple seconds at the most. Could be you are out of
disk space or RAM???

3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...

Finally, after about 30 seconds I received a warning that d.erase wasn't
yet supported.

This may be related to the slow rendering issue. I get the message that
d.erase is not implemented immediately. Note that d.erase should be easy to
implement.

I like the idea here, but the speed of rendering is far too slow for
standard usage.

Clearly this is far too slow, but the rendering speed (or rather its lack)
is not a function of either the console or wxPython canvas in this case. Is
it that slow when you display from the layer manager too?

Have you tried it for other commands -- all the non display commands? Other
shell commands? Any thoughts?

All commands seem to have a delay-- even executing g.region causes the CPU to
jump to 100% for about 15 seconds.

Cheers,
Dylan

Michael

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[Dylan_Beaudette]

On Tuesday 15 December 2009, Michael Barton wrote:

What is your OS?

Something is very squirrelly. I'm also looking at spearfish. All displays
should be in a second or two; commands like r.info should be instantaneous.
I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo. So it's not as hot as
your machine.

Do you have any other strange issues/messages with the GUI or Python?

Michael

Hi,

No obvious issues, however the GUI does take about 20 seconds to load. OS is
Debian/Unstable.

Here is the version info of the wx-related stuff:

libwxbase2.8-0 2.8.7.1-2+b1
python-wxgtk2.8 2.8.7.1-2+b1
wx2.8-headers 2.8.7.1-2+b1

Cheers,
Dylan

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:
> On Tuesday 15 December 2009, Michael Barton wrote:
>> Hi Dylan,
>>
>> Thanks very much for trying this out. A few responses below.
>>
>> On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:
>>> Hi Michael,
>>>
>>> I applied the patch, and it almost works. After running a command, I am
>>> not presented with a new line-- I need to erase the last command in
>>> order to enter a new one.
>>
>> This seemed weird so I tried it out. This only happens with d.*
>> commands. I don't know why, but am sure that it is fixable.
>
> Hi,
>
> OK. I'll wait and see how things develop with the d.* commands. Overall,
> I really like the idea, and command-completion is a real time saver!
>
>>> Also, there is about a 45 second delay between a d.rast command and
>>> output on the canvas... Do you know what could be causing this?
>>
>> Mine shows up in a second or two. I'm not sure what is causing this but
>> can speculate a little. First, have you turned on the 'constrain display
>> resolution to computational region settings' in the preferences? If so,
>> and if you have a map with a lot of cells, this will render slowly
>> because d.rast has to write out a file with that many pixels, then on
>> the fly compress them into the size that fits into your screen window.
>> This would be the case with any image renderer. The default is to turn
>> this off and have intelligent rendering, where the graphic file rendered
>> by d.rast is sized to match the display window in advance. So it writes
>> comparatively few pixels. For most purposes, GRASS should stay in this
>> mode because you can only see the number of pixels in your display
>> window, regardless of the number of cells in your map.
>
> I checked, and the 'constrain display resolution to computational region
> settings' box was un-checked. I am working with the default Spearfish
> region, so this really isn't all that many cells.
>
>> If you do not have the 'constrain display resolution..' mode set this
>> way, I'm don't know what the problem is. Even very large maps display
>> quite quickly for me--in a couple seconds at the most. Could be you are
>> out of disk space or RAM???
>
> 3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...
>
>>> Finally, after about 30 seconds I received a warning that d.erase
>>> wasn't yet supported.
>>
>> This may be related to the slow rendering issue. I get the message that
>> d.erase is not implemented immediately. Note that d.erase should be easy
>> to implement.
>>
>>> I like the idea here, but the speed of rendering is far too slow for
>>> standard usage.
>>
>> Clearly this is far too slow, but the rendering speed (or rather its
>> lack) is not a function of either the console or wxPython canvas in this
>> case. Is it that slow when you display from the layer manager too?
>>
>> Have you tried it for other commands -- all the non display commands?
>> Other shell commands? Any thoughts?
>
> All commands seem to have a delay-- even executing g.region causes the
> CPU to jump to 100% for about 15 seconds.
>
> Cheers,
> Dylan
>
>> Michael
>
> --
> Dylan Beaudette
> Soil Resource Laboratory
> http://casoilresource.lawr.ucdavis.edu/
> University of California at Davis
> 530.754.7341

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[Hamish]

Dylan wrote:

All commands seem to have a delay-- even executing g.region
causes the CPU to jump to 100% for about 15 seconds.

time enough to run `top` and see what's the hog..

H

[cmbarton]

If d.erase were implemented in the GUI console, how should it work?

1) remove all maps and other displays from the layer tree
2) turn off all maps and other displays from the layer tree

#1 is what it did in an xmon, but that may not be the desired behavior in the current environment.

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 15, 2009, at 7:40 PM, Hamish wrote:

Dylan wrote:

All commands seem to have a delay-- even executing g.region
causes the CPU to jump to 100% for about 15 seconds.

time enough to run `top` and see what's the hog..

H

[martinl]

Hi,

2009/12/11 Michael Barton <michael.barton@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

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[cmbarton]

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

Hi,

2009/12/11 Michael Barton <michael.barton@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

[Glynn_Clements1]

Michael Barton wrote:

If d.erase were implemented in the GUI console, how should it work?

1) remove all maps and other displays from the layer tree
2) turn off all maps and other displays from the layer tree

#1 is what it did in an xmon, but that may not be the desired behavior in the current environment.

d.erase still exists, and works with direct rendering. The result a
blank image.

This may not be a great deal of use within the GUI, but it does work.
It is useful in other contexts (e.g. creating the initial image if you
intend to use GRASS_PNG_READ=TRUE for subsequent commands).

--
Glynn Clements <glynn@gclements.plus.com>

[martinl]

Hi,

2009/12/16 Michael Barton <Michael.Barton@asu.edu>:

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.

right, this what I was suggesting from the beginning. Feel free to
implement GPromptSTC. My personal meaning is that most of GUIs use
different widgets for input area (when you type commands) and log
area.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Dylan_Beaudette]

On Wednesday 16 December 2009, Michael Barton wrote:

Darn. All of my ideas about why this doesn't work right don't work. I guess
try what Hamish said.

Michael

OK--

This time, starting GRASS, and the GUI-- and raster and vector maps are
displayed within about 2-6 seconds. I wonder if this is a byte-code compiling
thing... the first time GRASS was run with the new modules = slow, closing
and opening again = fast?

looking at the output in top, I could see that a process called 'python' was
using 99% of CPU, and about 3% of available memory. Nothing else looked
suspicious.

I really like the auto-complete stuff, with a little work this may be a
workable alternative to the X11-based monitor. It is still about 2-3x slower
than the X11 version. Is the GUI faster on GRASS 7?

Thanks for all of the hard work!

Cheers,
Dylan

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Dec 16, 2009, at 10:18 AM, Dylan Beaudette wrote:
> On Wednesday 16 December 2009, Michael Barton wrote:
>> Do you have Python 2.5? Other version?
>>
>> Michael
>
> using python 2.5
>
> Dylan
>
>> ______________________________
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ 85287-2402
>> USA
>>
>> voice: 480-965-6262; fax: 480-965-7671
>> www: http://csdc.asu.edu, http://shesc.asu.edu
>> http://www.public.asu.edu/~cmbarton
>>
>> On Dec 15, 2009, at 5:32 PM, Dylan Beaudette wrote:
>>> On Tuesday 15 December 2009, Michael Barton wrote:
>>>> What is your OS?
>>>>
>>>> Something is very squirrelly. I'm also looking at spearfish. All
>>>> displays should be in a second or two; commands like r.info should be
>>>> instantaneous. I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo.
>>>> So it's not as hot as your machine.
>>>>
>>>> Do you have any other strange issues/messages with the GUI or Python?
>>>>
>>>> Michael
>>>
>>> Hi,
>>>
>>> No obvious issues, however the GUI does take about 20 seconds to load.
>>> OS is Debian/Unstable.
>>>
>>> Here is the version info of the wx-related stuff:
>>>
>>> libwxbase2.8-0 2.8.7.1-2+b1
>>> python-wxgtk2.8 2.8.7.1-2+b1
>>> wx2.8-headers 2.8.7.1-2+b1
>>>
>>> Cheers,
>>> Dylan
>>>
>>>> Phone: 480-965-6262
>>>> Fax: 480-965-7671
>>>> www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>
>>>> On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:
>>>>> On Tuesday 15 December 2009, Michael Barton wrote:
>>>>>> Hi Dylan,
>>>>>>
>>>>>> Thanks very much for trying this out. A few responses below.
>>>>>>
>>>>>> On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> I applied the patch, and it almost works. After running a command,
>>>>>>> I am not presented with a new line-- I need to erase the last
>>>>>>> command in order to enter a new one.
>>>>>>
>>>>>> This seemed weird so I tried it out. This only happens with d.*
>>>>>> commands. I don't know why, but am sure that it is fixable.
>>>>>
>>>>> Hi,
>>>>>
>>>>> OK. I'll wait and see how things develop with the d.* commands.
>>>>> Overall, I really like the idea, and command-completion is a real
>>>>> time saver!
>>>>>
>>>>>>> Also, there is about a 45 second delay between a d.rast command and
>>>>>>> output on the canvas... Do you know what could be causing this?
>>>>>>
>>>>>> Mine shows up in a second or two. I'm not sure what is causing this
>>>>>> but can speculate a little. First, have you turned on the 'constrain
>>>>>> display resolution to computational region settings' in the
>>>>>> preferences? If so, and if you have a map with a lot of cells, this
>>>>>> will render slowly because d.rast has to write out a file with that
>>>>>> many pixels, then on the fly compress them into the size that fits
>>>>>> into your screen window. This would be the case with any image
>>>>>> renderer. The default is to turn this off and have intelligent
>>>>>> rendering, where the graphic file rendered by d.rast is sized to
>>>>>> match the display window in advance. So it writes comparatively few
>>>>>> pixels. For most purposes, GRASS should stay in this mode because
>>>>>> you can only see the number of pixels in your display window,
>>>>>> regardless of the number of cells in your map.
>>>>>
>>>>> I checked, and the 'constrain display resolution to computational
>>>>> region settings' box was un-checked. I am working with the default
>>>>> Spearfish region, so this really isn't all that many cells.
>>>>>
>>>>>> If you do not have the 'constrain display resolution..' mode set
>>>>>> this way, I'm don't know what the problem is. Even very large maps
>>>>>> display quite quickly for me--in a couple seconds at the most. Could
>>>>>> be you are out of disk space or RAM???
>>>>>
>>>>> 3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...
>>>>>
>>>>>>> Finally, after about 30 seconds I received a warning that d.erase
>>>>>>> wasn't yet supported.
>>>>>>
>>>>>> This may be related to the slow rendering issue. I get the message
>>>>>> that d.erase is not implemented immediately. Note that d.erase
>>>>>> should be easy to implement.
>>>>>>
>>>>>>> I like the idea here, but the speed of rendering is far too slow
>>>>>>> for standard usage.
>>>>>>
>>>>>> Clearly this is far too slow, but the rendering speed (or rather its
>>>>>> lack) is not a function of either the console or wxPython canvas in
>>>>>> this case. Is it that slow when you display from the layer manager
>>>>>> too?
>>>>>>
>>>>>> Have you tried it for other commands -- all the non display
>>>>>> commands? Other shell commands? Any thoughts?
>>>>>
>>>>> All commands seem to have a delay-- even executing g.region causes
>>>>> the CPU to jump to 100% for about 15 seconds.
>>>>>
>>>>> Cheers,
>>>>> Dylan
>>>>>
>>>>>> Michael
>>>>>

[Glynn_Clements1]

Michael Barton wrote:

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.

I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

--
Glynn Clements <glynn@gclements.plus.com>

[cmbarton]

This makes some sense.

Python compiles at runtime. So the first time you run the GUI, each module will compile the first time it is run. Subsequently, all modules will run the compiled code. If you update and the code in a compiled and uncompiled module do not match, that module will compile the first time you use it again.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Dec 16, 2009, at 10:34 AM, Dylan Beaudette wrote:

On Wednesday 16 December 2009, Michael Barton wrote:

Darn. All of my ideas about why this doesn't work right don't work. I guess
try what Hamish said.

Michael

OK--

This time, starting GRASS, and the GUI-- and raster and vector maps are
displayed within about 2-6 seconds. I wonder if this is a byte-code compiling
thing... the first time GRASS was run with the new modules = slow, closing
and opening again = fast?

looking at the output in top, I could see that a process called 'python' was
using 99% of CPU, and about 3% of available memory. Nothing else looked
suspicious.

I really like the auto-complete stuff, with a little work this may be a
workable alternative to the X11-based monitor. It is still about 2-3x slower
than the X11 version. Is the GUI faster on GRASS 7?

Thanks for all of the hard work!

Cheers,
Dylan

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Dec 16, 2009, at 10:18 AM, Dylan Beaudette wrote:

On Wednesday 16 December 2009, Michael Barton wrote:

Do you have Python 2.5? Other version?

Michael

using python 2.5

Dylan

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Dec 15, 2009, at 5:32 PM, Dylan Beaudette wrote:

On Tuesday 15 December 2009, Michael Barton wrote:

What is your OS?

Something is very squirrelly. I'm also looking at spearfish. All
displays should be in a second or two; commands like r.info should be
instantaneous. I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo.
So it's not as hot as your machine.

Do you have any other strange issues/messages with the GUI or Python?

Michael

Hi,

No obvious issues, however the GUI does take about 20 seconds to load.
OS is Debian/Unstable.

Here is the version info of the wx-related stuff:

libwxbase2.8-0 2.8.7.1-2+b1
python-wxgtk2.8 2.8.7.1-2+b1
wx2.8-headers 2.8.7.1-2+b1

Cheers,
Dylan

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:

On Tuesday 15 December 2009, Michael Barton wrote:

Hi Dylan,

Thanks very much for trying this out. A few responses below.

On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:

Hi Michael,

I applied the patch, and it almost works. After running a command,
I am not presented with a new line-- I need to erase the last
command in order to enter a new one.

This seemed weird so I tried it out. This only happens with d.*
commands. I don't know why, but am sure that it is fixable.

Hi,

OK. I'll wait and see how things develop with the d.* commands.
Overall, I really like the idea, and command-completion is a real
time saver!

Also, there is about a 45 second delay between a d.rast command and
output on the canvas... Do you know what could be causing this?

Mine shows up in a second or two. I'm not sure what is causing this
but can speculate a little. First, have you turned on the 'constrain
display resolution to computational region settings' in the
preferences? If so, and if you have a map with a lot of cells, this
will render slowly because d.rast has to write out a file with that
many pixels, then on the fly compress them into the size that fits
into your screen window. This would be the case with any image
renderer. The default is to turn this off and have intelligent
rendering, where the graphic file rendered by d.rast is sized to
match the display window in advance. So it writes comparatively few
pixels. For most purposes, GRASS should stay in this mode because
you can only see the number of pixels in your display window,
regardless of the number of cells in your map.

I checked, and the 'constrain display resolution to computational
region settings' box was un-checked. I am working with the default
Spearfish region, so this really isn't all that many cells.

If you do not have the 'constrain display resolution..' mode set
this way, I'm don't know what the problem is. Even very large maps
display quite quickly for me--in a couple seconds at the most. Could
be you are out of disk space or RAM???

3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...

Finally, after about 30 seconds I received a warning that d.erase
wasn't yet supported.

This may be related to the slow rendering issue. I get the message
that d.erase is not implemented immediately. Note that d.erase
should be easy to implement.

I like the idea here, but the speed of rendering is far too slow
for standard usage.

Clearly this is far too slow, but the rendering speed (or rather its
lack) is not a function of either the console or wxPython canvas in
this case. Is it that slow when you display from the layer manager
too?

Have you tried it for other commands -- all the non display
commands? Other shell commands? Any thoughts?

All commands seem to have a delay-- even executing g.region causes
the CPU to jump to 100% for about 15 seconds.

Cheers,
Dylan

Michael

[martinl]

Hi,

2009/12/16 Glynn Clements <glynn@gclements.plus.com>:

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.

I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

I agree, GPrompt should be improved in this way...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[martinl]

2009/12/16 Martin Landa <landa.martin@gmail.com>:

I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical

sorry do you mean separate windows or widgets (in the sense of SDI)?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa