Re: Actions for GailButton

[Bill Haneman <Bill Haneman sun com>]

>Hi guys,
>
>If I read Padraig correctly, one couldn't initiate a "click" without first
>calling "activate", yes?  

I don't think so.  'activate' was the original action name, I think the proposal is 
to call it 'click' instead. 

>Presumably a voice control system would dynamically build a recognition
>grammar from the available manipulable items, and then scan for matches to
>that grammar in order to ascertain what the user wants to do and then do it.
>
>So, a user might say "Click OK" to do the "click" action on the active
>Accessible object whose accessible name was "OK".  "Click OK Button" would
>disambiguate it via the objects' accessible role.  I certainly don't want to
>have to say "Activate OK", "Click OK".

nope, you shouldn't have to.

>For this kind of "harvesting" of actions (and selections and such) into
>dynamic grammars, consistency is very important.  It shouldn't be "click"
>for one kind of widget, and "active" for another, "toggle" for a third - all
>of which seem to be functionally the same thing.

ok, this works is they really *are* functionally the same.  The purpose of the 
discussion is to choose the level of abstraction appropriately, so as not to lose 
functionality (below).  

>Peter


>P.S. This is a place where accessible selection comes into play nicely -
>it's very natural to want to say "Select File" to activate (pop-down) the
>File menu, followed by "Select Print".  It's not that hard a stretch to have
>the voice recognition system be able to take a following "Print" after
>"Select File", knowing that Print is the accessible name of something
>selectable in a window that just appeared (and was newly added to the
>grammar).
>
>P.P.S. here is another area where consistancy is important across GUI
>toolkits.  It shouldn't be "Click" in the Java Accessibility API, "Toggle"
>in GTK+, and yet other things other places...

doesn't matter at the toolkit level, the bridging technologies can enforce 
consistency at the spi level.

the issue is with 'similar' components that have slightly different semantics.  Marc 
pointed out that a single 'activate' action for all buttons is insufficient for some 
use cases, so one ends up with multiple action names for buttons since different 
button types support different interaction behaviors (for instance, a toggle button 
should not distinguish between press and release, other button types may).

I would suggest that toggle buttons support 'click' only, 'regular' buttons support 
three events including 'click' as Marc suggests (or we can call it 'activate', 
doesn't matter as long as we are consistent).  I think that since the meaning of 
'click' depends on mouse settings, 'click' is probably the right word.  I think that 
in GTK+ you only get a 'click' event if the press/release cycle is short, otherwise 
you get separate 'press' and 'release' events... if one always gets all three then I 
question whether it makes as much sense to support three events as opposed to just 
two.

-Bill

>
>Marc Mulcahy wrote:
>> 
>> Padraig,
>> 
>> My comments below.
>> 
>> At 05:52 PM 7/12/2001 +0100, Padraig O'Briain wrote:
>> >Marc,
>> >
>> >I have examined the proposed actions and my findings are below; comments
>> >requested.
>> >
>> >I think we need three actions:
>> >
>> >GtkButton.press
>> >GtkButton.release
>> >GtkButton.activate
>> >
>> >Pressed
>> >=======
>> >I assume that this action should simulate a button press. I am calling this
>> >action GtkButton.press.
>> >
>> >I have implemented this as follows:
>> >
>> >       button->in_button = TRUE;
>> >       gtk_button_enter (button);
>> >       gtk_button_pressed (button);
>> >
>> >That is, it simulates the mouse moving into the button followed by
>> >pressing the left mouse button.
>> >
>> >*** Looks right to me
>> >
>> >Released
>> >========
>> >I am calling this action GtkButton.release.
>> >
>> >There are two cases to consider here, the mouse being released inside and
>> >outside the button.
>> >
>> >The mouse button being released outside the button can be implemented as
>> >
>> >       button->in_button = FALSE;
>> >       gtk_button_leave (button);
>> >       gtk_button_released (button);
>> >
>> >The mouse button being released inside the button can be implemented
>> >as part of the click action.
>> >
>> >** Again, looks right.
>> >
>> >Clicked
>> >=======
>> >Initially the click action was simple, just call gtk_button_clicked (button);
>> >now this action could be called after GtkButton.press action. I now have
>> >the following implementation:
>> >
>> >       if (button->button_down)
>> >       {
>> >         button->in_button = TRUE;
>> >         gtk_button_enter (button);
>> >         gtk_button_released (button);
>> >       }
>> >       else
>> >         gtk_button_clicked (button);
>> >
>> >
>> >Activate
>> >========
>> >I call this GtkButton.activate and it is implemented as
>> >
>> >       gtk_widget_activate (GTK_WIDGET (widget));
>> >
>> >This action seems to have the same effect as GtkButton.click and should,
>> >I think, be used instead of it.
>> >
>> >** My only response to this discussion is that I wonder how much semantic
>> >information screen readers/other assistive tech will try to glean from
>> >these action names.  Herein, I think, lies the importance of names such as
>> >"click" and "toggle" rather than "activate".  What does everyone else think?
>> 
>> Marc
>> 
>> _______________________________________________
>> gnome-accessibility-list mailing list
>> gnome-accessibility-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
>_______________________________________________
>gnome-accessibility-list mailing list
>gnome-accessibility-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland