wxGUI command layer broken and unusable

[garu]

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

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

Michael

[glynn]

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

[cmbarton]

It has always worked so that the user has to enter a command and all needed arguments. These must be parsed.

[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

[glynn]

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

[cmbarton]

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

[cmbarton]

Replying to glynn:

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

Michael

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

[hamish]

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

some small tweaking still required..

Hamish

[cmbarton]

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.

[annakrat]

I have made a few changes in grass 7, could you test if it helps at least with some of the issues?

Anna

[cmbarton]

Just recompiled and tested. It is now useable. You can see what you are typing. I tried it with d.rast aspect in the nc_spm_08 demo set.

Thanks Michael

[annakrat]

Backported to release branch in 54952.

Points 2) and 5) are still valid but these issues are related to wx and it's not easy to fix them. The rest should be fixed. I decrease the priority.

[wenzeslaus]

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.