[GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and updates

Michael Barton wrote:

>> modifying zooming again. Zooming now stays on until you press the right
>> mouse button. This matches the other display controls. However, I agree with
>> Glynn that this does not follow interface guidelines exactly (the right
>> button for Windows and Mac, at least, is reserved for contextual menus). But
>> I don¹t have a better solution for how to stop the the action of these tools
>> for the moment. Double clicking is often used by graphic programs, but I
>> worry that a misplaced double click will change a zoom or pan. I could use a
>> key-click combination, but don¹t know which, if any, are considered standard
>> for stopping tool actions (Anyone have some real information on this?). A
>> potentially good idea is to make the buttons work like radio buttons and add
>> a pointer button. GIMP works this way. However, if possible, this would take
>> some creative programming and time to do it. I¹ll keep it in mind. If anyone
>> wants to tackle it....
>
> The usual mechanism is a set of radio buttons to select the current
> "tool". Zoom would be one of the tools.
>
> I'm not sure what you mean by "creative programming". Tk has radio
> buttons; for use in a toolbar/toolbox, use "-indicatoron off" to use
> the button's relief to reflect the activation state (rather than
> having a separate indicator).

I was thinking I'd have to program the buttons' various state
configurations. I'd like the buttons to have a similar appearance to what
they have now (with icons and the like).

I don't know if radio buttons can be made in that way (rather than simple
diamonds/circles).

Yes; that's the point of "-indicatoron false". E.g.:

set gmpath gui/tcltk/gis.m
radiobutton .a -indicatoron false -image [image create photo -file "$gmpath/raster.gif"] -variable tool -value raster
radiobutton .b -indicatoron false -image [image create photo -file "$gmpath/vector.gif"] -variable tool -value vector
radiobutton .c -indicatoron false -image [image create photo -file "$gmpath/group.gif"] -variable tool -value group
pack .a .b .c -side left
set tool raster

Maybe they can, but I haven't done it yet and would have
to figure it out and redo the tool bar. Also, by switching to radio buttons,
each button would not call a particular command, but set a variable. I
suppose I'd need a switch statement then to actually issue the commands.

For a GUI program which has different "modes" of operation, the
handler for mouse events is usually a switch statement which calls
different procedures depending upon the current mode.

Maybe this is the best way to go. It will just take some time to work it out
and implement it.

It's likely to be the most intuitive solution, as it mimics the way
that most similar applications work.

If you only have one or two mouse-driven operations, it's viable to
assign specific functions to specific button/modifier combinations. As
the number of operations increases, eventually you will need to just
delegate mouse events to mode-specific handlers.

--
Glynn Clements <glynn@gclements.plus.com>

I spent some time today working with radiobuttons as you describe below. I
like the result and hope to have something to commit to the cvs (if the cvs
locations are fixed) next week.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 18 Feb 2006 19:21:01 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Grass Developers List <grass5@grass.itc.it>
Subject: Re: [GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
updates

Michael Barton wrote:

modifying zooming again. Zooming now stays on until you press the right
mouse button. This matches the other display controls. However, I agree
with
Glynn that this does not follow interface guidelines exactly (the right
button for Windows and Mac, at least, is reserved for contextual menus).
But
I don¹t have a better solution for how to stop the the action of these
tools
for the moment. Double clicking is often used by graphic programs, but I
worry that a misplaced double click will change a zoom or pan. I could use
a
key-click combination, but don¹t know which, if any, are considered
standard
for stopping tool actions (Anyone have some real information on this?). A
potentially good idea is to make the buttons work like radio buttons and
add
a pointer button. GIMP works this way. However, if possible, this would
take
some creative programming and time to do it. I¹ll keep it in mind. If
anyone
wants to tackle it....

The usual mechanism is a set of radio buttons to select the current
"tool". Zoom would be one of the tools.

I'm not sure what you mean by "creative programming". Tk has radio
buttons; for use in a toolbar/toolbox, use "-indicatoron off" to use
the button's relief to reflect the activation state (rather than
having a separate indicator).

I was thinking I'd have to program the buttons' various state
configurations. I'd like the buttons to have a similar appearance to what
they have now (with icons and the like).

I don't know if radio buttons can be made in that way (rather than simple
diamonds/circles).

Yes; that's the point of "-indicatoron false". E.g.:

set gmpath gui/tcltk/gis.m
radiobutton .a -indicatoron false -image [image create photo -file
"$gmpath/raster.gif"] -variable tool -value raster
radiobutton .b -indicatoron false -image [image create photo -file
"$gmpath/vector.gif"] -variable tool -value vector
radiobutton .c -indicatoron false -image [image create photo -file
"$gmpath/group.gif"] -variable tool -value group
pack .a .b .c -side left
set tool raster

Maybe they can, but I haven't done it yet and would have
to figure it out and redo the tool bar. Also, by switching to radio buttons,
each button would not call a particular command, but set a variable. I
suppose I'd need a switch statement then to actually issue the commands.

For a GUI program which has different "modes" of operation, the
handler for mouse events is usually a switch statement which calls
different procedures depending upon the current mode.

Maybe this is the best way to go. It will just take some time to work it out
and implement it.

It's likely to be the most intuitive solution, as it mimics the way
that most similar applications work.

If you only have one or two mouse-driven operations, it's viable to
assign specific functions to specific button/modifier combinations. As
the number of operations increases, eventually you will need to just
delegate mouse events to mode-specific handlers.

--
Glynn Clements <glynn@gclements.plus.com>