[GRASS-dev] some impressions on the wx interface

[Michael Barton]

Thanks for more comments. See below for some responses and ideas.

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

voice: 	480-965-6262; fax: 480-965-7671
www: 	http://csdc.asu.edu, http://shesc.asu.edu
		http://www.public.asu.edu/~cmbarton

On Sep 11, 2009, at 2:12 PM, grass-dev-request at lists.osgeo.org wrote:

> Date: Fri, 11 Sep 2009 13:28:56 -0400
> From: Helena Mitasova <hmitaso at unity.ncsu.edu>
> Subject: Re: [GRASS-dev] some impressions on the wx interface
> To: Carlos Grohmann <carlos.grohmann at gmail.com>
> Cc: grass-dev <grass-dev at lists.osgeo.org>
> Message-ID: <CFF877E3-0A7D-4920-88B0-85F9709F9926 at unity.ncsu.edu>
> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
>        format=flowed
>
> Little bit of cosmetics to wxGUI would indeed help, especially for
> new users - see my comments below:
>
> On Sep 11, 2009, at 11:01 AM, Carlos Grohmann wrote:
>
>> One thing is that the WX interface doesn't open a terminal (at least
>> in Windows), so if one is thinking about running GRASS+R, with GRASS
>> on top of R, there is no way. Or is there?
>
> yes, there is, we open GRASS using GRASS+MSYS icon (the one with
> grass and blue M)
> and that opens wxGUI and shell. This makes the environment on linux,  
> Mac
> and WinGRASS very similar to each other and so far worked great for  
> me.
>
> 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 generic X window. To get an image into a canvas (TclTk  
or wxPython) is considerably more complicated, though you can do a lot  
more with it once it's there.

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

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.

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

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.

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

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

>
> 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 found that some
> people who learned TclTK GUI stick to it and are hesitant to switch.

Change is hard sometimes.

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


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

>> why? the arrows to scroll to tabs
>> that may not be visible is OK (although I would prefer to have all  
>> the
>> tabs shown, even if that meant two rows of tabs),

2 rows of tabs is not an option in wxpython, or at least not an easy  
option.

>> but closing tabs
>> shouldn't be an option. Maybe we can save some space using regular
>> "square" tabs instead of the tabs with that triangular ending.

Because the square right end of a fancy tab overlaps the triangular  
left tab of the next tab to the right, we save little or no space by  
going to rectangular tabs. IMHO, the fancy tabs are easier to see as  
tabs than the rectangular ones in some circumstances (e.g., the tabs  
at the top of the layer manager if you have multiple displays vs. the  
rectangular ones at the bottom that seem difficult to recognize). The  
only way to avoid the arrows is to have wider dialogs. Some tab  
widgets don't have the arrows on the right, but just hide the tabs.

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

>>
>> And I noticed that I can't change the HTML browser (Ubuntu 9.04,
>> latest GRASS SVN). It always call Konqueror. I tried changing
>> GRASS_HTML_BROWSER to firefox or chromium-browser, but  
>> unsuccessfully.

Someone else commented on this. Not sure how to fix it. I think it is  
set in g.manual.

>>
>> that's it for now. I'll use only the WX interface now, so I might  
>> come
>> back with more feedback soon.
>>
>> cheers
>>
>> Carlos
>>
>