Re: Actions for GailButton



Peter,

> 
> Hi guys,
> 
> If I read Padraig correctly, one couldn't initiate a "click" without first
> calling "activate", yes?  I think there are two main use cases for Actions


No. Currently there is an action called "activate" but there is not one called 
"click". My reading of your mail was that you are suggesting that we should 
rename the action called "activate" to "click" for consistentcy. I am 
confortable with that although Marc may not be. Theses are his comments from the 
end of this mail.

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


Padraig

> -> getting wired up to non-tradition physical input devices (Braille
> keyboards, etc.), and for voice control.  For the former, some level of
> complexity is probably not a problem.  For the latter, I'm a little
> concerned about complexity.  
> 
> 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".
> 
> 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.
> 
> 
> 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...
> 
> 
> 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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]