[GRASSGUI] qgis interface alike

[Daniel Calvelo]

Hi all,

The current wx-based development of a GRASS GUI follows the line of
tcltkgrass, d.m, gis.m and provides graphical interactive access to
the whole GRASS functionality.

The approach taken by Radim in the QGIS GRASS plugin is rather
different: he provides full CLI access for advanced use on the one
hand, and on the other he provides graphical shortcuts for common
operations, needing a reduced set of parameters (the rest using either
defaults or special values according to each "shortcut").

I was thinking about leveraging Radim's work, building a Python parser
for his .qgm format, basically reusing qgis-grass plugin's module tree
and providing this same "fast" commands for the wx-based interface.

But we're talking about different philosophies here. How do you think
both could be merged in a way that wouldn't be unintuitive to a new
GRASS user? Would separating the interface in "basic" and "advanced"
functionality be desirable? Can the qgis plugin interface make sense
as a "quick toolbox" alongside the heavier wxgui? Would this
integration be worthwhile from a user standpoint?

Daniel.

[Michael Barton]

The rationale for the plugin architecture in QGIS is that is it
fundamentally a map display program, rather than a full-featured GIS. Using
the plugins is a way to embed analytical and map development capabilities
into QGIS while maintaining the basic architecture. However, to make this
work, you need to have QGIS and GRASS installed.

The way wxGRASS (and the TclTk) architecture works is to wrap all of GRASS
in a GUI, rather than build a GUI and then add in some GRASS. I'm not sure
what would be served by building a GUI wrapper for GRASS that only accesses
a limited part of the code base.

What might make more sense, in terms of flexibility, is to make selected
GRASS commands also available (i.e., beyond the complex menu hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since trying to
create a tool box for all 300+ commands would result in an interface as
complicated as the menus themselves, maybe we could make a tool box that
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

Michael

Post by Daniel Calvelo
Hi all,
The current wx-based development of a GRASS GUI follows the line of
tcltkgrass, d.m, gis.m and provides graphical interactive access to
the whole GRASS functionality.
The approach taken by Radim in the QGIS GRASS plugin is rather
different: he provides full CLI access for advanced use on the one
hand, and on the other he provides graphical shortcuts for common
operations, needing a reduced set of parameters (the rest using either
defaults or special values according to each "shortcut").
I was thinking about leveraging Radim's work, building a Python parser
for his .qgm format, basically reusing qgis-grass plugin's module tree
and providing this same "fast" commands for the wx-based interface.
But we're talking about different philosophies here. How do you think
both could be merged in a way that wouldn't be unintuitive to a new
GRASS user? Would separating the interface in "basic" and "advanced"
functionality be desirable? Can the qgis plugin interface make sense
as a "quick toolbox" alongside the heavier wxgui? Would this
integration be worthwhile from a user standpoint?
Daniel.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Daniel Calvelo]

Post by Michael Barton
The rationale for the plugin architecture in QGIS is that is it
fundamentally a map display program, rather than a full-featured GIS. Using
the plugins is a way to embed analytical and map development capabilities
into QGIS while maintaining the basic architecture.

Yes. That helps enormously when trying to introduce somebody to it.

Post by Michael Barton
However, to make this work, you need to have QGIS and GRASS installed.

That was my point: to leverage the GRASS plugin toolbox, you don't
need QGIS; all you need is the "definitions" for the plugin commands
and some programming. Those definitions are the equivalent of
menudata.py in current wx effort. They define an iconset, a subset of
grass-command parameters and a set of default values, so there is not
a one-to-one mapping between those plugin-commands and grass-commands.
It adds a layer of flexibility.

And it could be further expanded, in terms of usability. Consider e.g.
r.slope.aspect ; in the qgis plugin, in becomes two plugin-commands:
r.slope.aspect.slope and r.slope.aspect.aspect, which produce
respectively only the slope and only the aspect by feeding the
appropriate parameters to the grass-command. What do you gain? You can
default input to the select "layer", and you can default output to a
machine-generated name. So you do it all in one button click.

Post by Michael Barton
The way wxGRASS (and the TclTk) architecture works is to wrap all of GRASS
in a GUI, rather than build a GUI and then add in some GRASS. I'm not sure
what would be served by building a GUI wrapper for GRASS that only accesses
a limited part of the code base.

I was trying to discuss the reuse of Radim's "GRASS toolkit" idea
within our current effort, not suggesting reimplementing QGIS.

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make selected
GRASS commands also available (i.e., beyond the complex menu hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since trying to
create a tool box for all 300+ commands would result in an interface as
complicated as the menus themselves, maybe we could make a tool box that
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense as a
"quick toolbox" alongside the heavier wxgui?". My concern is whether
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.

I like the idea of having task-related or thematic groupings. Another
fine idea from Radim is the building of the command icons with a very
simple symbology; that might help making those thematic toolboxes
friendlier.

Thanks,

Daniel.

Post by Michael Barton
Michael

Post by Daniel Calvelo
Hi all,
The current wx-based development of a GRASS GUI follows the line of
tcltkgrass, d.m, gis.m and provides graphical interactive access to
the whole GRASS functionality.
The approach taken by Radim in the QGIS GRASS plugin is rather
different: he provides full CLI access for advanced use on the one
hand, and on the other he provides graphical shortcuts for common
operations, needing a reduced set of parameters (the rest using either
defaults or special values according to each "shortcut").
I was thinking about leveraging Radim's work, building a Python parser
for his .qgm format, basically reusing qgis-grass plugin's module tree
and providing this same "fast" commands for the wx-based interface.
But we're talking about different philosophies here. How do you think
both could be merged in a way that wouldn't be unintuitive to a new
GRASS user? Would separating the interface in "basic" and "advanced"
functionality be desirable? Can the qgis plugin interface make sense
as a "quick toolbox" alongside the heavier wxgui? Would this
integration be worthwhile from a user standpoint?
Daniel.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Moritz Lennert]

GIS.

Post by Daniel Calvelo

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make selected
GRASS commands also available (i.e., beyond the complex menu
hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since trying to
create a tool box for all 300+ commands would result in an interface as
complicated as the menus themselves, maybe we could make a tool box that
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense as a
"quick toolbox" alongside the heavier wxgui?". My concern is whether
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings. Another
fine idea from Radim is the building of the command icons with a very
simple symbology; that might help making those thematic toolboxes
friendlier.

I think that having the possibility of easily creating customized
toolboxes would be very helpful. This would allow us, for example, to
create a specific toolbox for a course grouping only those commands you
really need, with reasonable defaults, etc. This would be a very nice
tool to ease entry into GRASS.

So, yes, I like Daniel's idea (and Radim's work ;-) ), since with it the
user only has to edit text files and add a few images to create such a
customised tool.

Moritz

[Jachym Cepicky]

Hi,
costumized toolboxes (or module menus) are required by some users. I suggest:

1) create $HOME/.grass directory as directory for user settings
2) introduce another environment variabl $GISRCDIR (or similar)
3) create $GISRCDIR/gui
3) create $GISRCDIR/gui/custom
4) custom menus could be simple text (csv) or XML files stored in
$GISRCDIR/gui/custom

jachym

Post by Moritz Lennert
GIS.

Post by Daniel Calvelo

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make selected
GRASS commands also available (i.e., beyond the complex menu hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since trying to
create a tool box for all 300+ commands would result in an interface as
complicated as the menus themselves, maybe we could make a tool box that
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense as a
"quick toolbox" alongside the heavier wxgui?". My concern is whether
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings. Another
fine idea from Radim is the building of the command icons with a very
simple symbology; that might help making those thematic toolboxes
friendlier.

I think that having the possibility of easily creating customized
toolboxes would be very helpful. This would allow us, for example, to
create a specific toolbox for a course grouping only those commands you
really need, with reasonable defaults, etc. This would be a very nice
tool to ease entry into GRASS.
So, yes, I like Daniel's idea (and Radim's work ;-) ), since with it the
user only has to edit text files and add a few images to create such a
customised tool.
Moritz
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

[William Kyngesburye]

Post by Jachym Cepicky
Hi,
1) create $HOME/.grass directory as directory for user settings
2) introduce another environment variabl $GISRCDIR (or similar)
3) create $GISRCDIR/gui
3) create $GISRCDIR/gui/custom
4) custom menus could be simple text (csv) or XML files stored in
$GISRCDIR/gui/custom
jachym

This gets into something I've been working on in the OSX build
system. A user configuration dir. Before anyone sets anything that
may be hard to change in the future, that $HOME/.grass (is that what
you intend GISRCDIR to be?) should be configurable during the build,
with appropriate defaults per platform.

For OSX, that would be $HOME/Library/GRASS, at least. I already have
that in the OSX app build, and extended further by adding a GRASS
version: $HOME/Library/GRASS/6.3. Currently, user addon modules are
stored here in "Modules".

Linux platforms could be ~/.grass. Windows would probably be
different, though similar to OSX - somewhere in a user's home
preferences/config dir, whatever that is.

Post by Jachym Cepicky

Post by Michael Barton
GIS.

Post by Daniel Calvelo

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make

selected

Post by Daniel Calvelo

Post by Michael Barton
GRASS commands also available (i.e., beyond the complex menu hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since

trying to

Post by Daniel Calvelo

Post by Michael Barton
create a tool box for all 300+ commands would result in an

interface as

Post by Daniel Calvelo

Post by Michael Barton
complicated as the menus themselves, maybe we could make a tool

box that

Post by Daniel Calvelo

Post by Michael Barton
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense

as a

Post by Daniel Calvelo
"quick toolbox" alongside the heavier wxgui?". My concern is

whether

Post by Daniel Calvelo
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings.

Another

Post by Daniel Calvelo
fine idea from Radim is the building of the command icons with a

very

Post by Daniel Calvelo
simple symbology; that might help making those thematic toolboxes
friendlier.

I think that having the possibility of easily creating customized
toolboxes would be very helpful. This would allow us, for example, to
create a specific toolbox for a course grouping only those
commands you
really need, with reasonable defaults, etc. This would be a very nice
tool to ease entry into GRASS.
So, yes, I like Daniel's idea (and Radim's work ;-) ), since with it the
user only has to edit text files and add a few images to create such a
customised tool.

-----
William Kyngesburye <***@kyngchaos.com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed
robot?

[Marvin] You think you have problems? What are you supposed to do
if you ARE a maniacally depressed robot? No, don't try and answer,
I'm 50,000 times more intelligent than you and even I don't know the
answer...

- HitchHiker's Guide to the Galaxy

[Jachym Cepicky]

hi,

Fwd: grass-dev

Post by William Kyngesburye

Post by Jachym Cepicky
Hi,
1) create $HOME/.grass directory as directory for user settings
2) introduce another environment variabl $GISRCDIR (or similar)
3) create $GISRCDIR/gui
3) create $GISRCDIR/gui/custom
4) custom menus could be simple text (csv) or XML files stored in
$GISRCDIR/gui/custom
jachym

This gets into something I've been working on in the OSX build
system. A user configuration dir. Before anyone sets anything that
may be hard to change in the future, that $HOME/.grass (is that what
you intend GISRCDIR to be?) should be configurable during the build,
with appropriate defaults per platform.

yes,

jachym

Post by William Kyngesburye
For OSX, that would be $HOME/Library/GRASS, at least. I already have
that in the OSX app build, and extended further by adding a GRASS
version: $HOME/Library/GRASS/6.3. Currently, user addon modules are
stored here in "Modules".
Linux platforms could be ~/.grass. Windows would probably be
different, though similar to OSX - somewhere in a user's home
preferences/config dir, whatever that is.

ok

Post by William Kyngesburye

Post by Jachym Cepicky

Post by Michael Barton
GIS.

Post by Daniel Calvelo

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make

selected

Post by Daniel Calvelo

Post by Michael Barton
GRASS commands also available (i.e., beyond the complex menu hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since

trying to

Post by Daniel Calvelo

Post by Michael Barton
create a tool box for all 300+ commands would result in an

interface as

Post by Daniel Calvelo

Post by Michael Barton
complicated as the menus themselves, maybe we could make a tool

box that

Post by Daniel Calvelo

Post by Michael Barton
lets users 'plug in' or remove different command groups (e.g., hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense

as a

Post by Daniel Calvelo
"quick toolbox" alongside the heavier wxgui?". My concern is

whether

Post by Daniel Calvelo
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings.

Another

Post by Daniel Calvelo
fine idea from Radim is the building of the command icons with a

very

Post by Daniel Calvelo
simple symbology; that might help making those thematic toolboxes
friendlier.

I think that having the possibility of easily creating customized
toolboxes would be very helpful. This would allow us, for example, to
create a specific toolbox for a course grouping only those
commands you
really need, with reasonable defaults, etc. This would be a very nice
tool to ease entry into GRASS.
So, yes, I like Daniel's idea (and Radim's work ;-) ), since with it the
user only has to edit text files and add a few images to create such a
customised tool.

-----
http://www.kyngchaos.com/
[Trillian] What are you supposed to do WITH a maniacally depressed
robot?
[Marvin] You think you have problems? What are you supposed to do
if you ARE a maniacally depressed robot? No, don't try and answer,
I'm 50,000 times more intelligent than you and even I don't know the
answer...
- HitchHiker's Guide to the Galaxy

[Michael Barton]

Post by Daniel Calvelo
That's what I meant by "Can the qgis plugin interface make sense as a
"quick toolbox" alongside the heavier wxgui?". My concern is whether
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings. Another
fine idea from Radim is the building of the command icons with a very
simple symbology; that might help making those thematic toolboxes
friendlier.

I guess I don't understand the programming implications of the plugin
architecture.

I think that a toolbox idea is worth exploring when we have the rest of the
GUI well in hand (and it's coming along more rapidly than I would have
predicted).

I like the command icons and symbology. We really need an icon designer to
join this group.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

If we get a toolbox function running, this would be a nice idea. Also useful
for custom addons.

Michael

Post by Jachym Cepicky
Hi,
1) create $HOME/.grass directory as directory for user settings
2) introduce another environment variabl $GISRCDIR (or similar)
3) create $GISRCDIR/gui
3) create $GISRCDIR/gui/custom
4) custom menus could be simple text (csv) or XML files stored in
$GISRCDIR/gui/custom
jachym

Post by Moritz Lennert
GIS.

Post by Daniel Calvelo

Post by Michael Barton
What might make more sense, in terms of flexibility, is to make selected
GRASS commands also available (i.e., beyond the complex menu
hierarchy) via
a graphical 'tool box', as Trevor Wiens has suggested. Since trying to
create a tool box for all 300+ commands would result in an interface as
complicated as the menus themselves, maybe we could make a tool box that
lets users 'plug in' or remove different command groups (e.g.,
hydrology or
terrain).

That's what I meant by "Can the qgis plugin interface make sense as a
"quick toolbox" alongside the heavier wxgui?". My concern is whether
and how that would confuse users (especially newcomers) instead of
giving them a gentler learning curve.
I like the idea of having task-related or thematic groupings. Another
fine idea from Radim is the building of the command icons with a very
simple symbology; that might help making those thematic toolboxes
friendlier.

I think that having the possibility of easily creating customized
toolboxes would be very helpful. This would allow us, for example, to
create a specific toolbox for a course grouping only those commands you
really need, with reasonable defaults, etc. This would be a very nice
tool to ease entry into GRASS.
So, yes, I like Daniel's idea (and Radim's work ;-) ), since with it the
user only has to edit text files and add a few images to create such a
customised tool.
Moritz
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton