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

Michael Barton michael.barton at asu.edu
Sat Feb 18 16:31:28 EST 2006

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 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 at gclements.plus.com>
> Date: Sat, 18 Feb 2006 19:21:01 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Grass Developers List <grass5 at 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 at gclements.plus.com>

More information about the grass-dev mailing list