[GRASS-dev] some impressions on the wx interface

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@lists.osgeo.org wrote:

Date: Fri, 11 Sep 2009 13:28:56 -0400
From: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: [GRASS-dev] some impressions on the wx interface
To: Carlos Grohmann <carlos.grohmann@gmail.com>
Cc: grass-dev <grass-dev@lists.osgeo.org>
Message-ID: <CFF877E3-0A7D-4920-88B0-85F9709F9926@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

Michael Barton wrote:

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

The commands work fine; they just behave differently in terms of where
the resulting image ends up.

Remember, they dumped displays to a generic X window.

They generated output via the current monitor, which may or may not
have been an X monitor.

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.

Trying to recognise d.* commands prior to execution is unwise; e.g.
this probably won't work if the command is a user script which invokes
d.* commands.

It would make more sense to assume that any command may generate
output, and to allow for this by setting all relevant environment
variables.

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.

I'm unaware of any planned changes to the way that the display library
works. I'm not anticipating any significant changes, although specific
features can be added if necessary.

--
Glynn Clements <glynn@gclements.plus.com>

Hi,

2009/9/12 Michael Barton <michael.barton@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

Hi,

2009/9/12 Martin Landa <landa.martin@gmail.com>:

[...]

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

Fixed in r39137.

Martin

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

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

Martin - I am not suggesting any major change here, I was suggesting two
things:

- given that wxGUI is already default in winGRASS, why wait for 6.5 for Mac and Linux?
   It should not delay 6.4 release. We could also go back to TclTk with WinGRASS
   to keep consistency in binaries, but I am not sure it is a good idea to do a major release
with default GUI that is not being maintained any more.

- by polishing wxGUI I meant what we are doing right now - fixing help page,
fix any bugs or weird behaviors that show up
during testing and perhaps make minimal changes to icons or descriptions,
such as the "Add overlay" issue. There may be more issues like this in TclTK GUI
than wxGUI, but there is nobody is going to fix those.

Helena