<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 23, 2015 at 7:15 AM, Paulo van Breugel <span dir="ltr"><<a href="mailto:p.vanbreugel@gmail.com" target="_blank">p.vanbreugel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, Dec 23, 2015 at 12:19 PM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
In a response to #2632 [1], I changed v.db.select in trunk (r67337) in order to reorder parameters in the module GUI and group what I consider the most important parameters in a 'Main' tab.<br>
<br>
I know there has been much discussion about parameter grouping in the GUI before and I don't want to impose my choices here. So, I'm more than happy to revert if necessary.<br>
<br>
The main idea is to ease the use of module GUIs without giving up their complete power. In other words, simplify, without dumming down. If, for a module, there are some parameters that seem the most obvious ones to change, then why not regroup them in a 'Main' tab, while leaving the other, more specialised ones, in separate tabs ?<br></blockquote><div><br></div></span><div>I am all in favour of this. Easier for the casual user and it means less clicks for probably most user-cases. I guess it will not always be easy to determine what are the most important / common parameters, but for this module I think you got them all right under the main tab.</div></blockquote></div><br></div><div class="gmail_extra">Moritz, I agree we need to improve this and I like what you did with v.db.select.<br><br>However, I think that the concept of Main tab as general rule for all modules will not work. But I think that it could work as yet another style of creating groups. Some modules are fine with Required and Optional. Some with Input and Output. Some need this Main or whatever is the right name. If it is done correctly, then I believe users can handle more than one tab (if Input and Output have 10 options each then it clearly something which needs to be fixed; probably with the approach you propose).<br><br>It seems to me that Main is not a good name. Something like Basic seems better as it is "all the basic things you need to set". v.db.select is doing select. But v.db.select's Main tab ("the most important ones") doesn't contain anything for actual selection. That's why it seems more like Basic. <br><br>A side note: Although Basic would suggest that there should be Advanced, the things should be split into more tabs/groups when they are not basic.<br><br></div><div class="gmail_extra">Also, if the Main in v.db.select is aimed of export of the whole table as CSV then perhaps we need a separate module (wrapper) to do that.<br></div><div class="gmail_extra"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 23, 2015 at 8:08 AM, Blumentrath, Stefan <span dir="ltr"><<a href="mailto:Stefan.Blumentrath@nina.no" target="_blank">Stefan.Blumentrath@nina.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">Such
 a “main” tab maight also be helpful to generate the GUI of the 
QGIS-GRASS-Plugin more automatically so that  module
 updates can be passed more easily to QGIS. I contributed to update of 
the module files (.qgm) which aimed exactly at reducing complexity 
</span></p></blockquote><div><br></div><div>If the complexity needs to be reduced, it needs to be reduced in GRASS GUI as well and that's exactly what the groups are for. Technically, adding/changing group is a trivial one-liner in both Python and C, see e.g.<br><br><a href="https://trac.osgeo.org/grass/changeset/62405">https://trac.osgeo.org/grass/changeset/62405</a><br><a href="https://trac.osgeo.org/grass/changeset/67337">https://trac.osgeo.org/grass/changeset/67337</a><br><a href="https://trac.osgeo.org/grass/changeset/39114">https://trac.osgeo.org/grass/changeset/39114</a><br><a href="https://trac.osgeo.org/grass/changeset/66453">https://trac.osgeo.org/grass/changeset/66453</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">(though some modules got split up there e.g. based on layer geometry 
types).</span></p></blockquote><div><br></div><div>I can imagine that at least some of these could be actual modules in GRASS. I think that v.to.3d with it's v.to.2d functionality is a candidate for a wrapper module. Together with the same tabs, not having pseudo GRASS modules in QGIS could greatly simplify life of users moving back and forth between QGIS and GRASS GIS as well as writing tutorials for one or the other.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"> As Paulo says, not always easy to determine
 what is “main”, but doable and a bit of work too...</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US"> </span></p></blockquote><div><br></div><div>I suppose you can copy some things from the .qgm files.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)" lang="EN-US">For the possible benefits regarding the QGIS integration that means practically, that the workload of module parameter
 simplification is passed to GRASS devs...</span></p></blockquote></div><br></div>In open source development model, it is always better to solve the issues upstream, more precisely, to submit your fixes upstream.<br><br></div><div class="gmail_extra">Vaclav<br></div></div>