I personally don't mind separate input and output windows.
-1
I would like to see:
1 Tab for the layer manager, 2dn tab for the command window.
Maybe there could be the option to optionally redirect the output into a
text file in
/tmp/grass.log?
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.
2009/12/16 Tim Michelsen <timmichelsen@gmx-topmail.de>:
I personally don't mind separate input and output windows.
-1
I would like to see:
1 Tab for the layer manager, 2dn tab for the command window.
Maybe there could be the option to optionally redirect the output into a
text file in
/tmp/grass.log?
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.
+1
wxGUI should support also MDI [1]. More then two windows in SDI could
be too many...
+1 add support for MDI
+1 keep two windows (Map Display and Layer Manager) in SDI (sure you
can open more Map Displays)
+1 keep separated command prompt and log area as different widgets
>> 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)?
Widgets. I.e. typing into a different area of the GUI to where the
output appears. There isn't much reason for them to use the same
widget. Terminal emulators have to emulate terminals (which are used
for e.g. curses applications as well as shells), but there's no reason
for a dedicated GUI command-line to behave that way.
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.
could be. I'm not sure what else could python be up to?
just to note: the first time you start it everything (including python and
libraries) have to be read from the disk which takes a little while. The
second time it is likely to still be cached in memory so cpu or ram bound,
not disk i/o bound.
also, for installed versions it's important that the .pyc byte compiled
binaries are created at build time, as once installed the user starting
grass probably won't have write permission to $GISBASE.
I just rebuilt to confirm if that's happening -- yep, they get built.
[If they weren't you'd have to start grass once as root to get the .pyc
files actually written to disk, but a "make check" no-op could be run as
part of the build process to create them before 'make install' or the
package installation. AFAIK they are portable (within reason).]
I've got no idea how to test if the installed versions are up-to-date
& so not rebuilt even though on disk. maybe run as root and see if the
timestamp on the installed ones update?? anyway if you have modified
wxgui.py and don't have write permission to $GISBASE then you may have
to wait for it each time.
>> 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)?
Widgets. I.e. typing into a different area of the GUI to where the
output appears. There isn't much reason for them to use the same
widget. Terminal emulators have to emulate terminals (which are used
for e.g. curses applications as well as shells), but there's no reason
for a dedicated GUI command-line to behave that way.
I just committed an advanced command console in develbranch_6 r40053. The changes were too many to do a diff. Please give it a spin.
There are separate input and output widgets. The input widget has all the features described below. It also wraps the command so you can see it all without resizing the window or scrolling. As before, typing commands that return text will produce nice output in the output widget; typing d.* command that display something (i.e., non-interactive ones) will produce something in the display canvas.
There is now a console tab/page with the command input and output widgets, and a layer manager tab/page with display layers you can manipulate with a GUI. Upside: a cleaner, more compact, interface with all command-related controls grouped together (and somewhat easier to code). Previously, entering a command would switch to the output tab/page anyway if it was not already selected. Downside: if you display maps using d.* commands and then want to manage the display layers (drag-and-drop layer organization, change properties), you have to click the tab for the layer manager.
The only thing I'm still having trouble with is sizing the StyledTextCtrl widgets for input and output. I think the input widget should be a little shorter but neither STC's are responding to sizing methods. This should be solvable, but at least you can try out new command entry console in the meantime.
Michael
On Dec 11, 2009, at 3:16 PM, 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.
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
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.
Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920
.r40052
It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)
See below
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]
Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.
With all these changes updating caused a conflict which I had to resolve before committing.
2009/12/19 Michael Barton <Michael.Barton@asu.edu>:
* completely breaks wxGUI
Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.
wxGUI didn't start, see error below. You committed file in a conflict.
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920
.r40052
It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.
Yes.
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)
See below
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]
Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.
As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.
What you are seeing is not the correct code. I'll fix this and try again.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
2009/12/19 Michael Barton <Michael.Barton@asu.edu>:
* completely breaks wxGUI
Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.
wxGUI didn't start, see error below. You committed file in a conflict.
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920
.r40052
It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.
Yes.
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)
See below
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]
Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.
As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.
I need to get that fixed so that I can commit correctly.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
2009/12/19 Michael Barton <Michael.Barton@asu.edu>:
* completely breaks wxGUI
Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.
wxGUI didn't start, see error below. You committed file in a conflict.
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920
.r40052
It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.
Yes.
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)
See below
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]
Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.
As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.
Output classes are in goutput.py
Input class is still in prompt.py
The other classes in prompt.py were for items superseded by the new autocompletion and calltips built into the one input class. That's why they are gone. Prompt is a clean STC input prompt.
Michael
On Dec 19, 2009, at 11:44 AM, Martin Landa wrote:
2009/12/19 Michael Barton <Michael.Barton@asu.edu>:
I managed to fix my subversion setup and get the changes to prompt.py, goutput.py, and wxgui.py committed properly.
Please test. Should be no conflict issues this time.
Beside conflict you just ignored what I was suggesting.
The output class does not contain the input class -- or at least it didn't, since I have no idea where it's at now.
I simply used the layout section of GConsole to fit this instance of GPrompt on the console page. GPrompt remains an independent class that can be used elsewhere if desired.
Michael
On Dec 19, 2009, at 12:15 PM, Martin Landa wrote:
2009/12/19 Martin Landa <landa.martin@gmail.com>:
2009/12/19 Michael Barton <Michael.Barton@asu.edu>:
Output classes are in goutput.py
well and the output class GConsole includes input class GPrompt. It's
not a good idea. It need to be redone.
Partly done in r40073. Just quick fix, need to rewritten.
