On Thu, Oct 8, 2015 at 10:47 PM, Blumentrath, Stefan <[email protected]> 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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
