[GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and updates
glynn at gclements.plus.com
Sat Feb 18 14:21:01 EST 2006
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
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 at gclements.plus.com>
More information about the grass-dev