[GRASS-dev] some impressions on the wx interface

[Martin Landa]

Hi,

2009/9/12 Michael Barton <michael.barton at asu.edu>:

[...]

>> The one very confusing thing is that when you try to run any d.* command
>> it says "not yet implemented" so it looks like unfinished thing which
>> may be OK
>> for RC but not for the final release. I suggest to change the message
>> to something
>> like "not applicable without X11 support, please use appropriate icons,
>> see wxGUI help" although people generally won't know what X11 is -
>> so maybe somebody has a better suggestion?
>>
>> And as I said before - I am missing the d.* commands  sooo much!
>
> The old d.* commands will not work in GRASS 7...at all because of the change
> in the underlying display architecture. Remember, they dumped displays to a

They could work, but it needs some developer to implement it. First
step would be to implement d.mon for wx displays. Then you should be
able to start wxGUI Display Window from CLI, e.g., d.mon wx0. I hope
it will be done for 7.0.

> The reason for the message is that Jachim Czpicky originally, and Martin
> Landa subsequently have thought about the possibility of having the command
> parser recognize a d.* command and display the result in a wxpython canvas.
> This sort of works in the Mac and Unix from the wxpython command parser, but
> I don't think that the python scripts to do this from a terminal are
> functional (Martin can correct me on this if I'm wrong).

They are not functional, but could be after probably little work. But
it was just designed as temporally solution - as I mentioned we need
d.mon back suitable to work with wxGUI displays.

> However, it seems to me better to wait until the display architecture is
> more finalized in GRASS 7 to do this. You can still display in x11 on GRASS
> 6 however. Maybe we should change the message for windows, however. I'm not
> sure where that message would live if you are talking about this from the
> Msys terminal.

Right.

>>> I noticed that the students were using most the "load map layers into
>>> workspace" icon, instead of "add raster" or "add vector". I don't know
>>> if this is because "load maps" is more to the left of the toolbar, and
>>> if you read from left to right, you see it before the others. I think
>>> that it would be better if the three "workspace" icons were at the far
>>> right of the toolbar. Also I would put the "add raster" and "add
>>> vector" icons  with a different image, to highlight them from the
>>> others.
>>
> There seems some logic to putting all the layer add buttons to the left and
> the workspace buttons to the right, but I don't have strong feelings about
> it.
>> I am not sure about this - I did not observe students using load map
>> layers
>>  - maybe you have shown
>> the students the load map layers first and they stick to it even
>> after they find out
>> about add raster.

>From my POV Layer Toolbar seems quite intuitive/standard to me. On the
left-most side are located icons which manage workspace (new, open,
save). The most GUI application which I use have also file-management
icons on the left (new/open/save file) side. "Load map layers" is
useful when you want to add more map layers in one shot. Otherwise
it's more easy to click on icon to add raster/vector map layer (also
note key shortcuts added recently to GRASS 6.5 and 7.0) [1].

>>> In the Map Display, the "overlay" icon doesn't really mean much, I
>>> think that a different image would help, or even three buttons, one
>>> for legend, one for north arrow and on for text.
>>
>> YES!!! Everybody here complains that they cannot find the legend button.
>> Even if you read the wxGUI help - it is hard to remember.
>
> Robert's new proposed button is much better.

+1

>>> In GIS manager, it looks to me that the "maps for each display" and
>>> "command output" are tabs, right? using a wx.notebook? in this case, I
>>> have to say that they don't look like tabs, and this always got me a
>>> little confused. If they had a real tab-like appearance, it would be
>>> better to understand the way the GUI works, because anyone that's new
>>> to the interface would know that there are two tabs with different
>>> contents.
>>
>> I would agree with this, although most students figured this out.
>
> Maybe change the background color of the bar behind the tabs if that is
> possible?

It's just matter of style which is currently used. Probably I would
prefer to use no style with default look-and-feel.

>> Given that wxGUI is completely new and minimally tested by broader
>> users community it is quite amazing how robust it is and I would vote
>> for releasing it as a default GUI for both Mac and linux, as it is
>> now for winGRASS. It may be worth to spend some time on polishing
>> it for GRASS64 final release, rather than having to maintain two GUIs
>
> I agree.

I am not sure if we can do such major change in this stage (after 5
rcs and probably few weeks before final release). It would require
other RC - in this case I would vote against. I would be happy to see
6.4.0 out even with TCL/TK as default, but soon. We can choose wxGUI
as default in 6.5 (which should be out quite soon).

>>> Also it would be very nice if instead of "maps for each
>>> display", we had "maps for display 1", "maps for display 2", etc.
>>>
>>> Also, using the mouse scroll wheel to navigate between tabs, IMO, is a
>>> must-have.
>
> I've never used the mouse wheel to scroll between tabs. I just tried it on
> firefox and it doesn't work. Maybe it's a Linux thing.

I don't thing so.

>>> That includes all tabs, the display tabs in gism and the
>>> options tabs in the commands dialogs. I also noticed that one can
>>> "close" tabs in the command dialog.
>
> You should NOT be able to close tabs on a command dialog. The tabs just
> break up the GUI for the arguments into manageable pieces. You don't want to
> close any of these GUI pages or you will lose access to the module arguments
> (or help). They are not like pages in a browser.
>
> Note that closing a display closes the tab for that display in the layer
> manager.

Right, testing GRASS 6.4svn you are able to close display tabs (i.e.,
Map displays) not "Map layers for each display" or "Command output". I
don't see any problem here.

>>> The dialog name for r.shaded.relief is "raded.relief". Didn't check
>>> other dialogs.
>
> Looks OK on my Mac version. Maybe it is fixed now.

Not here, it's bug (will be fixed). It's probably due to 'sh' which is
replaced by default (shell script extension).

Martin

[1] http://trac.osgeo.org/grass/ticket/725

-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa