[GRASS-dev] module header definitions add: text/multiline and latex support?
Stefan.Blumentrath at nina.no
Fri Jan 16 00:04:13 PST 2015
>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.
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.
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...
From: grass-dev-bounces at lists.osgeo.org [mailto:grass-dev-bounces at 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.
grass-dev mailing list
grass-dev at lists.osgeo.org
More information about the grass-dev