[GRASSGUI] standalone module use

[Michael Barton]

I just updated from the svn. There are several changes related to ?stand
alone? module use.

Now, if I type a command (e.g., r.info) on the wxgrass command line (i.e.,
at the bottom of the GIS Manager), nothing happens. Before these changes it
opened one of the modules.

Looking at the changes to menuform, it looks like the idea is to add a new
tab/page for command output.

Besides needing to fix the problem with the wxgrass command line, we need to
have a bit of discussion about how we envision command line use of GRASS.

Here is what I?m beginning to think....

Linux always has a terminal.

Mac can have a terminal, but doesn?t usually.

Windows doesn?t normally have a terminal.

I guess, I?d thought that we were including a place to type commands and get
output built into wxgrass so that we didn?t have to worry about using a
terminal or not?especially because it is not a normal features of Mac and
Windows platforms. That is, typing from a terminal outside of wxgrass is
certainly OK, but should not be required.

However, I think that output from grass commands run in the wxgrass GUI
environment should always go to the same place, regardless of how they are
launched. So that means that either the command output should go to a
command output tab on each module dialog OR to the single command output
window in the GIS Manager. It should not have to be directed to one place if
the module is launched from one command line and another place if it is
launched from another command line.

Having the module output show up IN the module notebook seems like a good
idea. But IMHO, if we go that way, then the output from a module dialog
should go there ALL the time. In that case, the only reason to have the
command output window in the GIS Manager is for shell commands and GRASS
commands run from the command line only (i.e., not from an autogenerated
dialog). In that case, we might as well get rid of the small command line
and turn the GIS Manager output window into a full Python terminal. This
would then be available on all platforms, obviating the need for a terminal
for GRASS. It will work the same and have access to the same abilities in
all platforms, regardless of whether they normally have a terminal window or
not.

What do you think?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-gui/attachments/20070328/db8628b2/attachment.html

[Jachym Cepicky]

hi,

Post by Michael Barton
Now, if I type a command (e.g., r.info) on the wxgrass command line (i.e.,
at the bottom of the GIS Manager), nothing happens.

it works for me(?) revision 367

Post by Michael Barton
Looking at the changes to menuform, it looks like the idea is to add a new
tab/page for command output.

[...]

Post by Michael Barton
Linux always has a terminal.
Mac can have a terminal, but doesn't usually.
Windows doesn't normally have a terminal.
I guess, I'd thought that we were including a place to type commands and
get output built into wxgrass so that we didn't have to worry about using a
terminal or not?especially because it is not a normal features of Mac and
Windows platforms. That is, typing from a terminal outside of wxgrass is
certainly OK, but should not be required.

If we want to move more towards the GUI world, we IMHO need some
module output place in our GUI too. AFAIK windows command line is hard
to use, because of you can not e.g. copy & paste text using Ctrl+c &
Ctrl+v, what is essential.

To your last sentence: I would add, that "typing from a terminal
outside of wxgrass" should not be _omitted_ too.

Post by Michael Barton
However, I think that output from grass commands run in the wxgrass GUI
environment should always go to the same place, regardless of how they are
launched. So that means that either the command output should go to a
command output tab on each module dialog OR to the single command output
window in the GIS Manager. It should not have to be directed to one place if
the module is launched from one command line and another place if it is
launched from another command line.

I added this new tab, which sould be created *only* if the module is
lounched from CLI. Currently, if you run r.info from command line, you
get TCL/TK formular with the "Output" tab and if you launch it from
gis.m, you get the same formular without it. I see no difference
here(?) I just tryed to reimplement something, what is allready there.

It makes IMHO sence to add this tab to module formular only when the
module is started and NO GIS manager with output window exists.

Post by Michael Barton
Having the module output show up IN the module notebook seems like a good
idea. But IMHO, if we go that way, then the output from a module dialog
should go there ALL the time. In that case, the only reason to have the
command output window in the GIS Manager is for shell commands and GRASS
commands run from the command line only (i.e., not from an autogenerated
dialog). In that case, we might as well get rid of the small command line
and turn the GIS Manager output window into a full Python terminal. This
would then be available on all platforms, obviating the need for a terminal
for GRASS. It will work the same and have access to the same abilities in
all platforms, regardless of whether they normally have a terminal window or
not.
What do you think?
Michael

Currently, I doubt, there is a way, how to build full featured
terminal using python. However, if this would be possible, I would
vote for it.

Hint:
http://www.wxpython.org/py.php

Jachym

[Glynn Clements]

Post by Jachym Cepicky

Post by Michael Barton
Having the module output show up IN the module notebook seems like a good
idea. But IMHO, if we go that way, then the output from a module dialog
should go there ALL the time. In that case, the only reason to have the
command output window in the GIS Manager is for shell commands and GRASS
commands run from the command line only (i.e., not from an autogenerated
dialog). In that case, we might as well get rid of the small command line
and turn the GIS Manager output window into a full Python terminal. This
would then be available on all platforms, obviating the need for a terminal
for GRASS. It will work the same and have access to the same abilities in
all platforms, regardless of whether they normally have a terminal window or
not.

Currently, I doubt, there is a way, how to build full featured
terminal using python. However, if this would be possible, I would
vote for it.

That depends upon what you mean by "full-featured".

I don't see any reason for wxgrass to try to provide a character-cell
terminal for curses-based programs. Even pty support is problematic
(not available on Windows, AFAICT).

[Michael Barton]

Post by Jachym Cepicky
I added this new tab, which sould be created *only* if the module is
lounched from CLI. Currently, if you run r.info from command line, you
get TCL/TK formular with the "Output" tab and if you launch it from
gis.m, you get the same formular without it. I see no difference
here(?) I just tryed to reimplement something, what is allready there.
It makes IMHO sence to add this tab to module formular only when the
module is started and NO GIS manager with output window exists.

This was only working if the module was launched from the menus. My change
(which could be improved on) makes it work when the module is launched from
the wxgrass command line (i.e., at the bottom of the GIS Manager window).

IMHO, a user should expect that the output from a command should return to
the control that ran the command. This is nicely consistent and helps users
know what where to look. So, output from a module run from a dialog
generated with menuform (i.e. dialog launched from the menus or from a
command called without arguments from the command line) should always go to
the output tab of the module dialog. Output from a module run (i.e., with
arguments) from the wxgrass command line should go to wxgrass output window.
Output from a module run (i.e., with arguments) from the terminal should go
to the terminal.

One possible exception would be the echoed d.* command launched from the GIS
Manager ultimately. This has its options set in the dialog generated by
menuform. However, pressing OK, makes this dialog disappear. If we want to
preserve the command for people to see and copy, we might want it to echo to
the GIS Manager output window.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton