[Qgis-developer] New GRASS plugin: a test drive

[Radim Blazek]

On Thu, Oct 8, 2015 at 10:47 PM, Blumentrath, Stefan
<Stefan.Blumentrath at nina.no> wrote:
> Regarding the tools-widget UI, I noticed that the "Close Mapset" butten takes space from the module tabs. The old "Close mapset" button was much smaller.

Which 'old' button?  I think that the button is the same since it was
added in 2.11.

> Would it be possible to move that to the bottom of the GRASS module UI, where the Debug buttons are located (if debugging is activated)?

It would occupy one more line, debugging bar is usually hidden. I
could remove the text from the button to make it smaller, but I wanted
to express di difference between closing the widget and closing the
mapset.

> BTW, the tabs for the open modules can get pretty wide due to the icons (see e.g. v.db.join). Maybe better to use module names in the tabs?

It is hard to decide, maybe optional?

> Finally, I was wondering if it could be an idea to place all mapset related buttons (open / close / new / change mapset) at the bottom of the Modules dialogue

'New mapset' is rarely used, and for an existing location it is much
easier to create new mapset from browser. 'Open mapset' is something
which I would like to remove completely, once user get used to opening
mapsets from the browser. It is the last old style open dialog (in <
2.10 it was used also for rasters/vectors).

When I was adding the 'Close button', I considered also other places,
like toolbar or menu above the tabs widget, but I think that an
application should not have preferably more menus/toolbars than the
main application-wide.

> and to add a "manage mapset access" button, which runs the mapset picker for modifying the search path (g.mapsets -s) there as well? One (I if you like) can add g.mapsets with the s-flag as a module (I tested "g.mapsets -s" in the QGIS-GRASS-plugin and it starts the GRASS dialogue successfully), but it is probably better to have this option a bit more prominent (as it might come in handy with the new multiple map input option)?

My approach, since the plugin was introduced, is that we do not add a
GRASS modules since we have a decent, dedicated GUI in QGIS. That is
why I never liked things like nviz in QGIS. This approach was
partially overcome by reality and various hacks (IMO) requested by
users. In this case, I would really oppose to open GRASS GUI from
QGIS.

Maybe you manage to write a wrapper GRASS script for g.mapsets in
Python which fills 'mapset' options with existing mapsets and sets
'answer' to the mapsets in search path?

Radim