[GRASS-dev] grouping most important parameters in a 'main' tab

[Vaclav Petras]

On Wed, Dec 23, 2015 at 7:15 AM, Paulo van Breugel <p.vanbreugel at gmail.com>
wrote:

> On Wed, Dec 23, 2015 at 12:19 PM, Moritz Lennert <
> mlennert at club.worldonline.be> wrote:
>
>>
>> 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.
>>
>> 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.
>>
>> 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 ?
>>
>
> 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.
>

Moritz, I agree we need to improve this and I like what you did with
v.db.select.

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).

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.

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.

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.


On Wed, Dec 23, 2015 at 8:08 AM, Blumentrath, Stefan <
Stefan.Blumentrath at nina.no> wrote:

> 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
>

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.

https://trac.osgeo.org/grass/changeset/62405
https://trac.osgeo.org/grass/changeset/67337
https://trac.osgeo.org/grass/changeset/39114
https://trac.osgeo.org/grass/changeset/66453


> (though some modules got split up there e.g. based on layer geometry
> types).
>

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.


> As Paulo says, not always easy to determine what is “main”, but doable and
> a bit of work too...
>
>
>

I suppose you can copy some things from the .qgm files.


> For the possible benefits regarding the QGIS integration that means
> practically, that the workload of module parameter simplification is passed
> to GRASS devs...
>

In open source development model, it is always better to solve the issues
upstream, more precisely, to submit your fixes upstream.

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151223/462ec140/attachment.html>