[GRASS-dev] module header definitions add: text/multiline and latex support?

[Paulo van Breugel]

On Fri Jan 16 2015 at 9:04:15 AM Blumentrath, Stefan <
Stefan.Blumentrath at nina.no> wrote:

> Dear all,
>
> From a user-perspective, I would like to say that one of the big plusses
> of GRASS is it`s consistency over time (also in the GUI). The transition
> from TclTK to WXPython went so smoothly for me, because principles stood
> the same. Do not get me wrong, I am not against changes/improvements but I
> would advise to make only subtle changes, so users do not have to acquaint
> themselves with the software after each GUI change (like the poor fellas
> who had to re-learn their proprietary GIS when it went from 3.2/3.3 to
> 8.something and then again when 10.something came...) .
>
> In addition, for amateur-python/shell-script-writers like me the
> simplicity of creating a GUI for a new module is also a big advantage of
> GRASS. This simplicity should be maintained, regardless what new features
> are added to the GUI.
>

+1 This is really one of the great features of GRASS GIS.

>
> Finally, from my point of view the authors of the WXPython GUI did a
> really great job, I can see nothing confusing or scary in it, so I do not
> see urgent needs for changes in in the GUI in principle.
>

+1 To illustrate how useful the GUI of many functions are: I also fairly
often refer back to the GUI. Not really to use it (most I do is on the
command line) but as a reference to remember certain options or parameter
names. In other words. In other words, for me it serves as an alternative
more visual help. And I asked a beginning user, and she used it the same
way (start with the GUI, and copy the syntax to use in scripts), as she
finds it also easier to have a quick grasp of the options than the help
file.

>
> That`s said, the advantage of avoiding tabs would probably be that users
> need less clicks to fill in all information to run a module. However,
> having all options in one window (without tabs) may generate a high window,
> with probably the need to scroll down (or un-collapse the optional choices
> (if they were collapsed)). So for such modules the less-clicks-advantage is
> not that big...
>

I actually like the ability to group major function into tabs, especially
if there are many options (and I agree with the above, one should avoid the
need for scrolling). For me the main advantage of grouping of options in
one tab is the earlier mentioned option to group options that require one
single explanation line, and perhaps more important, to group options from
which the user need to fill in only one, at least one, etc. (some good
solutions were already suggested I think)

>
> Cheers
> Stefan
>
>
> -----Original Message-----
> From: grass-dev-bounces at lists.osgeo.org [mailto:grass-dev-bounces@
> lists.osgeo.org] On Behalf Of Nikos Alexandris
> Sent: 15. januar 2015 23:05
> To: Moritz Lennert
> Cc: Paulo van Breugel; GRASS-dev
> Subject: Re: [GRASS-dev] module header definitions add: text/multiline and
> latex support?
>
> On 15/01/15 13:34, Nikos Alexandris wrote:
>
> >> Just a very quick mockup, all-in-one page:
> >> <http://imgbin.org/index.php?page=image&id=21809>.  Note, the "Help"
> >> button and the "Manual" are duplicates, if I am not wrong. This adds
> >> up in overloading the interface.
>
> On 15.01.2015 14:55, Moritz Lennert wrote:
>
> > Interesting, but I have to admit that I do not see what the advantage
> > of this is compared to the tabs...
>
> Just an idea, it is.  It would be possible to have the optional stuff
> collapsible.
>
> Anyhow, the point is:  a GUI needs a designer's touch.  This is going to
> make the interface readable, and not confusing  or  scary (as my quick
> mockup is too, of course).  The same is valid for the Wiki, for which I
> failed, in the past, to get past the message "let's make our Wiki
> beautiful" up to the point where we could say "we do have a beautiful Wiki".
>
> I've had a nice course on interactive programming with Python, back in
> September.  And I do have a sense for what it takes to program a GUI.
> My understanding is that big changes are probably way out of the project's
> manpower.  And we can surely live with that.  Yet, if there are changes to
> happen, let them be step-wise and adhere to modern UI principles.
>
> Nikos
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150116/d91e6a8f/attachment.html>