[GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)

Dears, with the GRASS Community Sprint just around the corner, I want
to share some impressions and bug reports about the wxGUI.

Some are general, some are specific. All bugs/issues were found using
the latest svn.

GENERAL:

I said this before, the tabs in the wx gis manager should look like
real tabs. Currently, the bottom tabs (blue) don't look like 'normal'
tabs, so this can be potentially confusing for new users. Give them
the appearance of the upper tabs.

Improving drag-and-drop would be really helpful.

Also, when it comes to output of modules, we should have only one way
of doing it. Now some modules provide output in the gis manager window
(using on of the botom tabs), while others give output in the dialog
window. I think there should be only one kind of output.In my view, a
separated output window (like the tk gism) where _all_ output messages
would go, and one should be able to close without loosing info
(keeping a 'memory' of the session) or leave it open. I found myself
frequently trying to close the gism after inspecting some output info,
just to be reminded of what I was about to do when asked if I want to
save a workspace file.

One of the things that annoy me is the 'close dialog on finish'
option. I guess this was introduced to make GRASS look more like other
GIS packages, but honestly, it sucks. At leas for me, it is very
common to repeat the command with different settings, and I usually
forget to unset that option, being used to old-style GRASS GUI, so I
kind hate it. We could have a global preferences setting where we
could choose to 'close dialogs on finish' as default action or not.
But this would have to work for _all_ modules.
You can imagine how disappointing it is to run r.stats just to see the
dialog closing after calculations...

I also noticed that several modules fail to include the resulting map
in the tree

SPECIFIC
v.plane - I think the azimuth option here should be compass-oriented

r.to.rast3 - the 3D map is added to the tree, but when you call it
properties, it opens d.vect

r.slope.aspect - does not work with '@mapset' after the map name

r.in.gdal - the default dialog (import raster) locks access to gism. I
think it shouldn't, like the regular module dialogs

v.in.ogr - the default dialog (import vector) also locks access to
gism. Besides, in my machine, when I try to browse for files, it shows
nothing, even in a directory full of shapefiles (or any other format)

r.in.gdal - when I import a tiff, it creates map.red, map.blue,
map.green, but it adds 'map' to the tree, instead of an RGB composite.
Since 'map' doesn't exists, error messages galore.

Well, these are just personal ideas, but I hope they could be of use.

cheers

Carlos

--
Prof. Carlos Henrique Grohmann - Geologist D.Sc.
Institute of Geosciences - Univ. of São Paulo, Brazil
http://www.igc.usp.br/pessoais/guano
http://lattes.cnpq.br/5846052449613692
Linux User #89721
________________
Can’t stop the signal.

Hi,

2011/3/7 Carlos Grohmann <carlos.grohmann@gmail.com>:

Also, when it comes to output of modules, we should have only one way
of doing it. Now some modules provide output in the gis manager window
(using on of the botom tabs), while others give output in the dialog
window. I think there should be only one kind of output.In my view, a
separated output window (like the tk gism) where _all_ output messages
would go, and one should be able to close without loosing info
(keeping a 'memory' of the session) or leave it open. I found myself
frequently trying to close the gism after inspecting some output info,
just to be reminded of what I was about to do when asked if I want to
save a workspace file.

commands launched from Layer Manager command line prints their output
to the 'command output' tab. Separately launched modules print their
output to 'command output' tab in the module's GUI dialog. Redirecting
this messages to 'command output' tab in Layer Manager would avoid
running more commands at the same time. One solution would be to add
for every launched command separate tab in Layer Manager's 'command
output' . I am not sure what is better. Anyway creating separate
window is not good solution, the more windows the worse for the user.

One of the things that annoy me is the 'close dialog on finish'
option. I guess this was introduced to make GRASS look more like other
GIS packages, but honestly, it sucks. At leas for me, it is very
common to repeat the command with different settings, and I usually
forget to unset that option, being used to old-style GRASS GUI, so I
kind hate it. We could have a global preferences setting where we
could choose to 'close dialogs on finish' as default action or not.
But this would have to work for _all_ modules.
You can imagine how disappointing it is to run r.stats just to see the
dialog closing after calculations...

in r45601 I changed default settings to 'unchecked'. Anyway you are
always free to change this settings in Preferences dialog (command
tab).

Martin

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

On Mar 8, 2011, at 8:46 AM, Martin Landa wrote:

Hi,

2011/3/7 Carlos Grohmann <carlos.grohmann@gmail.com>:

Also, when it comes to output of modules, we should have only one way
of doing it. Now some modules provide output in the gis manager window
(using on of the botom tabs), while others give output in the dialog
window. I think there should be only one kind of output.In my view, a
separated output window (like the tk gism) where _all_ output messages
would go, and one should be able to close without loosing info
(keeping a 'memory' of the session) or leave it open. I found myself
frequently trying to close the gism after inspecting some output info,
just to be reminded of what I was about to do when asked if I want to
save a workspace file.

commands launched from Layer Manager command line prints their output
to the 'command output' tab. Separately launched modules print their
output to 'command output' tab in the module's GUI dialog. Redirecting
this messages to 'command output' tab in Layer Manager would avoid
running more commands at the same time. One solution would be to add
for every launched command separate tab in Layer Manager's 'command
output' . I am not sure what is better. Anyway creating separate
window is not good solution, the more windows the worse for the user.

Less Windows. I suggest at most three and preferably two- The layer manager, Map Window, and "if you have to" a command window. I normally have a text editor to script in open at the same time, and even with a second monitor this arrangment gets cluttered.

One of the things that annoy me is the 'close dialog on finish'
option. I guess this was introduced to make GRASS look more like other
GIS packages, but honestly, it sucks. At leas for me, it is very
common to repeat the command with different settings, and I usually
forget to unset that option, being used to old-style GRASS GUI, so I
kind hate it. We could have a global preferences setting where we
could choose to 'close dialogs on finish' as default action or not.
But this would have to work for _all_ modules.
You can imagine how disappointing it is to run r.stats just to see the
dialog closing after calculations...

in r45601 I changed default settings to 'unchecked'. Anyway you are
always free to change this settings in Preferences dialog (command
tab).

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

My two pennies

Stephen

On Tue, Mar 8, 2011 at 6:20 PM, stephen sefick <sas0025@auburn.edu> wrote:

On Mar 8, 2011, at 8:46 AM, Martin Landa wrote:

2011/3/7 Carlos Grohmann <carlos.grohmann@gmail.com>:

...

Anyway creating separate
window is not good solution, the more windows the worse for the user.

Less Windows. I suggest at most three and preferably two- The layer
manager, Map Window, and "if you have to" a command window. I normally have
a text editor to script in open at the same time, and even with a second
monitor this arrangment gets cluttered.

I agree with that (since I have already another tons of windows already open).
I have put a proposal here:

http://grass.osgeo.org/wiki/WxGUI#General_GUI_Design
-> Proposal for wxGUI layout modification (Recomposition of existing toolbars,
   mapview and menus)

which is essentially trapping the individual wxGUI windows in a single one.
At least optionally...

Markus

Hi,

2011/3/9 Markus Neteler <neteler@osgeo.org>:

http://grass.osgeo.org/wiki/WxGUI#General_GUI_Design
-> Proposal for wxGUI layout modification (Recomposition of existing toolbars,
mapview and menus)

which is essentially trapping the individual wxGUI windows in a single one.
At least optionally...

probably would be nice GSoC project(?)

Marttin

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

I can help, but this is my field season and I will be galavanting around the SE US.

On Mar 9, 2011, at 3:24 PM, Martin Landa wrote:

Hi,

2011/3/9 Markus Neteler <neteler@osgeo.org>:

http://grass.osgeo.org/wiki/WxGUI#General_GUI_Design
-> Proposal for wxGUI layout modification (Recomposition of existing toolbars,
  mapview and menus)

which is essentially trapping the individual wxGUI windows in a single one.
At least optionally...

probably would be nice GSoC project(?)

Marttin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Hello,
having console output in same window with layers is one of those small
tibits that make new GUI unproductive for daily use. Yeah, it might
hava bright future, but unless I can undock comand output to separate
window, it will continue to suck.

My proposal - do not try to copy ArcGIS/QGIS. With current manpower
and legacy we will not be able to do on same level or better. If it's
so - better don't. Keep GRASS different. Being able to drag separate
windows to different monitors etc. is one of GRASS strenghts.

Maris.

2011/3/9, Markus Neteler <neteler@osgeo.org>:

On Tue, Mar 8, 2011 at 6:20 PM, stephen sefick <sas0025@auburn.edu> wrote:

On Mar 8, 2011, at 8:46 AM, Martin Landa wrote:
Less Windows. I suggest at most three and preferably two- The layer

I agree with that (since I have already another tons of windows already
open).
which is essentially trapping the individual wxGUI windows in a single one.
At least optionally...

Markus

Hi,

2011/3/10 Maris Nartiss <maris.gis@gmail.com>:

having console output in same window with layers is one of those small
tibits that make new GUI unproductive for daily use. Yeah, it might
hava bright future, but unless I can undock comand output to separate
window, it will continue to suck.

I don't see any fundamental troubles here, at least with working key
shortcuts to switch between layer tree and output area.

My proposal - do not try to copy ArcGIS/QGIS. With current manpower
and legacy we will not be able to do on same level or better. If it's
so - better don't. Keep GRASS different. Being able to drag separate
windows to different monitors etc. is one of GRASS strenghts.

Good point.

Martin

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

On Thu, Mar 10, 2011 at 9:31 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/3/10 Maris Nartiss <maris.gis@gmail.com>:

having console output in same window with layers is one of those small
tibits that make new GUI unproductive for daily use. Yeah, it might
hava bright future, but unless I can undock comand output to separate
window, it will continue to suck.

I don't see any fundamental troubles here, at least with working key
shortcuts to switch between layer tree and output area.

My proposal - do not try to copy ArcGIS/QGIS. With current manpower
and legacy we will not be able to do on same level or better. If it's
so - better don't. Keep GRASS different. Being able to drag separate
windows to different monitors etc. is one of GRASS strenghts.

Good point.

Let the user decide... obviously there are two groups. So to make it optional
would be the best solution.

Markus