#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
(Grass Gis 6.4.0 embedded into Qgis 1.6.0)
The command layer support of wxGUI is completely broken and unusable.
(I'm new to Grass and i don't know Python so forgive me if what i'm saying
when talking about python code is not completely exact)
1) When creating a command layer the
{{{
wxgui_utils.AddLayer
}}}
creates the text box with
{{{
pos=wx.DefaultPosition, size=(self.GetSize()[0]-100,25)
}}}
but with an height of 25 and
{{{
wx.TE_DONTWRAP
}}}
the text box is completely filled with the horizontal scroll bar and
there's no room to enter the command. To have the room where to enter the
command the height should be at least 40.
2) Even when setting the height to 40 if the entered command exceeds the
horizontal visible space, the horizontal scroll bar has no effect. To
scroll you have to put the caret into the text box and scroll back and
forth using the arrow keys.
3) When dragging the command layer, in the
{{{
RecreateItem
}}}
the line
{{{
elif self.GetPyData(dragItem)[0]['type'] == 'command':
}}}
will never take control because for command layers the previous
{{{
if self.GetPyData(dragItem)[0]['ctrl']:
}}}
will always be true and the dropped control will be painted without the
text box.
4) Besides even if the above elif could execute, the command layer text
box would be painted with
{{{
pos=wx.DefaultPosition, size=(250,25)
}}}
that in any case is incorrect.
5) Since when the text box is initially created, the visible width is set
relative to the width of the Layer Manager panel, one would expect that
resizing the width of the Layer Manager panel would also resize
accordingly the visible part of the text box, but this does not happen.
BTW, from a basic overview it looks like the layertree.py in the trunk
suffers the same problems.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
I wonder if it is time to retire this layer type. In addition to the
errors reported above, are problems in parsing this accurately. It also
duplicates the functionality of other layer types but without the input
controls provided by the module setting dialogs. Finally, there is now a
nice command window to use for those so inclined, with auto completion,
tool-tips, etc.
The command layer is a relict of GRASS 5.0, where it was in the very
simple display manager. In that context, it allowed GRASS d.* commands not
available in the display manager to be run for display in an xterm window.
This is pretty archaic now and may not be worth keeping.
Because it is part of the interactive component, it does not figure in any
scripts. So removing it will have no impact in that regard.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:1 cmbarton]:
> I wonder if it is time to retire this layer type.
The command layer is the one layer type which is actually necessary.
Anything else is just a convenience.
It must be possible to add layers for arbitrary commands, so that the user
doesn't have to modify the GUI if they add new d.* commands or scripts.
> In addition to the errors reported above, are problems in parsing this
accurately.
If it's parsing anything, that's a design flaw. Once the command name is
entered, the parameters should be obtained using the module's parameter
dialog.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by garu):
Michael, i just began to scratch the Grass surface and for sure i've not
explored yet all the option and subtleties that the wxGUI interface
offers, so my opinion could be of scarce value, but afaik i've seen at
least two reasons to maintain the command layer:
1) it looks that Grass commands counts in the order of hundreds, do really
all of them have their graphical layer correspondence? I doubt, so i think
the command layer is the only option if a user wants to introduce in the
map stack some "esoteric" command.
2) in OS env, like Windoz, where shell programming is a real pain, command
layers can be a real help for rapid prototyping while still being able to
avail of the many facilities of the graphical interface.
I really hope you will reconsider your position, imo throwing away command
layer would be a real loss.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:4 garu]:
> 1) it looks that Grass commands counts in the order of hundreds, do
really all of them have their graphical layer correspondence? I doubt, so
i think the command layer is the only option if a user wants to introduce
in the map stack some "esoteric" command.
Most of them don't generate graphical output, so they can't be used from a
command layer. However, there are existing scripts which can generate
graphical output yet don't have a specific menu item in the GUI, and the
user can always create their own scripts which generate display output.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
Replying to [comment:4 garu]:
> Michael, i just began to scratch the Grass surface and for sure i've not
explored yet all the option and subtleties that the wxGUI interface
offers, so my opinion could be of scarce value, but afaik i've seen at
least two reasons to maintain the command layer:
>
> 1) it looks that Grass commands counts in the order of hundreds, do
really all of them have their graphical layer correspondence? I doubt, so
i think the command layer is the only option if a user wants to introduce
in the map stack some "esoteric" command.
>
> 2) in OS env, like Windoz, where shell programming is a real pain,
command layers can be a real help for rapid prototyping while still being
able to avail of the many facilities of the graphical interface.
>
> I really hope you will reconsider your position, imo throwing away
command layer would be a real loss.
>
> Gabriele
Gabriele,
You don't seem to understand how the command layer works. This is a place
to type *display* commands only. Nothing else will work here. These are a
very limited subset of the GRASS command set.
Let me announce to the readers yet again, AFAIK, GRASS will maintain the
ability to be controlled through typed commands into the farthest
foreseeable future. The ability to type commands is critically important
to the ability to script GRASS and some users love typing commands. Since
the first full GRASS GUI, I and the other people writing GUI code have not
only NOT tried to eliminate commands but have spent a fair amount of
coding to create special command processors in GUI for users (primarily
Windows) who don't have terminals and to make command use easier. Note
that all GUI dialogs have always have allowed you to cut/copy the command
they generate and paste it into a terminal, other command processor, or
script.
Any power user of GRASS should investigate the use of commands and
scripting. I suggest that you give the command console a spin. It is
accessed through a tab at the bottom of the main GIS control window. It
has command auto-completion, tool-tips (type 'tab'), command history, and
the ability to cut and paste commands.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
Replying to [comment:5 glynn]:
> Replying to [comment:4 garu]:
>
> > 1) it looks that Grass commands counts in the order of hundreds, do
really all of them have their graphical layer correspondence? I doubt, so
i think the command layer is the only option if a user wants to introduce
in the map stack some "esoteric" command.
>
> Most of them don't generate graphical output, so they can't be used from
a command layer. However, there are existing scripts which can generate
graphical output yet don't have a specific menu item in the GUI, and the
user can always create their own scripts which generate display output.
This is the best reason I've heard so far for trying to fix this. My point
to Gabrielle was simply that this is broken and wondered if there is a
reason to go to the effort to fix it since it duplicates other functions.
However, if a user writes a script that creates graphic output, it could
be nice to display the results along with other graphic layers and a
command layer is a good place to do this.
I agree that the most robust way for this to work is to have it mirror the
other display layers and pop up one of the GUI dialogs for setting
options. That way, it parses exactly like the other layers. To do this,
either a new button would need to be added to the command layer line (and
this could be more of a pain than it seems, give the way this control
works) or parse a special key (return or tab probably) to pop up the
settings dialog for the command.
#1239: wxGUI command layer broken and unusable
-------------------------+--------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
Component: wxGUI | Version: 6.4.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
I just want to note that the command layer is still broken. I can't type
anything in it (or at least see anything I type). It needs to be fixed or
removed.
Replying to [comment:8 cmbarton]:
> I just want to note that the command layer is still
> broken. I can't type anything in it (or at least see
> anything I type).
it's possible, but the widget packing isn't ideal so the box you have to
type into is way off to the right side.
try adding a command layer* to a fresh session with no other layers. e.g.
"`d.grid size=5000`"; the entry box seems reasonable.
[*] it's a little hard to find in the "Add grid or vector labels overlays"
drop down menu
then try adding a raster layer. the preferences button on the right of the
layer name pushes the text entry area of the command layer line above it
off to the right. the longer your map@mapset, the more it gets pushed off
to the right.
adding the command layer ''after'' the raster map makes the middle-packed
preferences button pack right in close to the right side of the map@mapset
text in the raster layer.
#1239: wxGUI command layer broken and unusable
---------------------------+------------------------------------------------
Reporter: garu | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: wxGUI | Version: 6.4.3 RCs
Keywords: layer manager | Platform: MSWindows XP
Cpu: Unspecified |
---------------------------+------------------------------------------------
Changes (by cmbarton):
* version: 6.4.0 => 6.4.3 RCs
Comment:
I just tried the command layer again and it is still unusable.
It doesn't work at all if it is the only layer. But if another layer is
added, they you can type a command into it if you make the layer manager
window big enough.
The problem is that you cannot see the command at all. I might be useful
in some cases (I had a use for it to try a d.vect.chart that also has a
problem from its GUI), but not if you cannot type into it or see what you
have typed when you do type into it.
It needs to be fixed or removed before the 6.4.3 release.
I'll see if I can update this afternoon after class and let you know. Thanks.
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
Since the most important parts of the ticket were fixed, closing the
ticket.
The remaining points does not fit the summary/title, are from different
category, have very different priority, are probably wontfix, and in any
case should be tracked separately. Please create new tickets with fresh
description of the problem, screenshots and suggestions. It would be
actually useful to identify problems with the layer tree in Layer Manager.
{{{
2) Even when setting the height to 40 if the entered command exceeds the
horizontal visible
space, the horizontal scroll bar has no effect. To scroll you have to put
the caret into the
text box and scroll back and forth using the arrow keys.
5) Since when the text box is initially created, the visible width is set
relative to the width
of the Layer Manager panel, one would expect that resizing the width of
the Layer Manager panel
would also resize accordingly the visible part of the text box, but this
does not happen.
}}}