Excellent work!
May I suggest one little addition:
it would be great to have different coloured
titles or even little icons for commands
from the r.* v.* r3.* etc sections.
On a screen full of command GUIs this would
make finding the right one a lot easier.
Also, it would be nice to have all optional
parameters at the end of the list/in a different
font or even only displayed when wanted
(sth. like a "show all options" tickbox?)
One last thing: a history funtion to recall the
last settings in a GUI form since reopening it
would make life so much easier ...
On Sunday 12 March 2006 22:18, Glynn Clements wrote:
> That seems reasonable, except that I would suggest leaving the
> label/desc entries untouched, and either moving the choice to the
> point where the value is actually used, or creating a separate entry
> in opts() and copying the label/desc entry to that instead.
I agree completely. This patch accomplishes nothing, really, except
to
separate the changes needed to set up for having a better gui.tcl
from the
new one when it comes. As such I was trying to keep the list of
changes to a
minimum. The changes included here are just enough to clean up the
calling
convention and add the guisection attribute which my plans for
gui.tcl hinge
on. Anyway, I just copied the program logic straight across between
languages
to have a nice clear and understandable commit.
I am working quite a bit on gui.tcl, which has a rather low cost of
modifying.
Right now I've got notification in the output screen with icons
when the
program starts and finishes running and display and update of the
command to
be run while the options are edited. I'm playing with balloon help,
separate
tabs for options and output, contemplating a help tab to go along
with them,
and am somewhere in the midst of writing my first experimental
layout rule.
If anyone else has any wishes for the generic GUI, now is a good time to kick
them around here.
On Monday 13 March 2006 02:30, benducke@compuserve.de wrote:
Excellent work!
May I suggest one little addition:
it would be great to have different coloured
titles or even little icons for commands
from the r.* v.* r3.* etc sections.
On a screen full of command GUIs this would
make finding the right one a lot easier.
Excellent idea. I'm already considering adding something like
$(GISBASE)/etc/icon that will be looked in for an icon for individual
commands (named something like r.in.gdal-.gif). I haven't put very much
thought into it yet. If/when I get there I'll check for generic icons too,
like r.in-.gif or r-.gif. I'm also planning on hijacking some of those nice
icons from Michael's work to use for some open existing prompts instead of
">".
Also, it would be nice to have all optional
parameters at the end of the list/in a different
font or even only displayed when wanted
(sth. like a "show all options" tickbox?)
I'm trying simple, more conventional layouts first. That (string; required)
stuff is definitely going to get right-justified at the least. A tree that
starts with only required options expanded by default and an expand all
button would definitely be something a gui could do.
One last thing: a history funtion to recall the
last settings in a GUI form since reopening it
would make life so much easier ...
Do you mean window size (which would be a gui side thing) or loading options
(which could be a parser thing, a gui thing, or even a third party thing)?
I'm nowhere near this sort of step yet, but having the parser still parse the
options when the gui command line switches are used seems like a compelling
idea and would make it easy for third party utilities to open the gui with
specific options selected already.
If anyone else has any wishes for the generic GUI, now is a good time to kick them around here.
Hi,
I have a wish about display, but maybe it's not concerning the "generic GUI".
It will be cool if the display resolution where "defaulted" to screen resolution when the "region resolution" is to big. Currently grass display all the cells, even if they aren't visible. With high resolution, display is very slow.
Sometimes it could be fine to have a high resolution for calculation and be able to pan without waiting.
I don't know how difficult it is, though.
I'm also planning on hijacking some of those nice icons from
Michael's work to use for some open existing prompts instead of ">".
Are all icons from other GPL or BSD/MIT projects fair game?
I'm already considering adding something like $(GISBASE)/etc/icon
If you do, please make that something like $(GISBASE)/etc/gui/icons
It is already confusing that the vector point symbols are often called
icons ($GISBASE/etc/symbol). Let's not make it any worse.
> Also, it would be nice to have all optional parameters at the end of
> the list
This should already be the case in most modules. It is controlled by the
order in which the options are defined in the source code. Sometimes it
happens this way out of oversight or modification*, other times it is on
purpose or conforming to a more import design consideration**.
[*] e.g. g.filename. I've just moved the newly optional mapset= option
to appear last.
[**] e.g. 'v.in.ascii [in=] out=' is best I think.
having the parser still parse the options when the gui command line
switches are used seems like a compelling idea and would make it easy
for third party utilities to open the gui with specific options
selected already.
careful, often a flag is the only command line option desired. Or none.
In fact the display resolution is not related to the data resolution, at
least in the new GIS Manager. The data resolution is set by g.region and the
display resolution is set by environmental variables GRASS_WIDTH and
GRASS_HEIGHT.
What slows things down at high resolution is doing exactly what you suggest.
The display modules recalculate and output their high resolution data to a
much lower resolution screen display. This recalculation takes some time.
But after it's done, the screen looks nice at lower resolution. Also, in the
new GIS Manager, if you've rendered this once and don't need to change the
way a layer is rendered, it is not re-rendered on subsequent displays--only
recomposited with other layers. This speeds things up a lot.
Michael
On 3/13/06 12:49 PM, "Laurent Courty" <lrntct@gmail.com> wrote:
Cedric Shock wrote:
Hi,
If anyone else has any wishes for the generic GUI, now is a good time to kick
them around here.
Hi,
I have a wish about display, but maybe it's not concerning the "generic
GUI".
It will be cool if the display resolution where "defaulted" to screen
resolution when the "region resolution" is to big. Currently grass
display all the cells, even if they aren't visible. With high
resolution, display is very slow.
Sometimes it could be fine to have a high resolution for calculation and
be able to pan without waiting.
I don't know how difficult it is, though.
Laurent
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287