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

[Michael Barton]

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 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>