standalone module use

[Michael Barton]

Some javascript/style in this post has been disabled (why?)

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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Jachym Cepicky]

hi,

2007/3/28, Michael Barton <[hidden email]>:
>  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

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

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

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

>
>  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
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Jachym Cepicky wrote:

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

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

On 3/29/07 1:45 AM, "Jachym Cepicky" <[hidden email]> wrote:

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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui