After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151417 - GOK needs to support multiple actions on UI components
GOK needs to support multiple actions on UI components
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other All
: High enhancement
: ---
Assigned To: bill.haneman
bill.haneman
AP1
Depends on:
Blocks:
 
 
Reported: 2004-08-30 12:29 UTC by bill.haneman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch against HEAD to provide this feature (8.69 KB, patch)
2004-09-24 16:28 UTC, bill.haneman
none Details | Review
slightly improved patch including ChangeLog (9.12 KB, patch)
2004-09-24 16:55 UTC, bill.haneman
none Details | Review

Description bill.haneman 2004-08-30 12:29:31 UTC
for instance, UI grab a treetable element which is both expandable and
selectable.  GOK has only one action, the "default" one for the component, which
it exposes in its UI Grab action keys.  In the above case, we'd like to be able
to toggle-expanded and/or select the corresponding table row, but GOK doesn't
let us distinguish.

To do so, activating a multi-actionable UI component in GOK should branch to an
'actions' keyboard exposing one button per available action (labelled with the
action name).

Probably should be a priority, as there are things in Mozilla and Evolution
which can't currently be done without going to the Compose keyboard.
Comment 1 David Bolter 2004-08-30 13:06:37 UTC
Agreed.  We always planned for this, but never implemented.  

grep 'multiple actions' gok-keyboard.c
* Widgets can have multiple actions - build a keyboard of them.

Comment 2 bill.haneman 2004-08-30 13:23:49 UTC
I'd say this is the only feature-y thing of high urgency now.
Comment 3 Jessie Li 2004-09-13 12:37:30 UTC
Except expanding and selecting, there is still another action, "double click"
with mouse. For example, one click will select the item, double click will
trigger the action on it, such as open a webpage for it in Mozilla. 

How about the third action: double click?
Comment 4 bill.haneman 2004-09-13 14:04:05 UTC
I am not in favor of action names that are indicative of specific "device
events".  Although we do have "click" in gtk+ buttons, the meaning is "click the
button", i.e. the on-screen "virtual" button, not "click the mouse button".

So the third action should be named something else, if there is a third action
that the user can do.  Also, if the user can do this third action with the mouse
the user _must_ be able to do it without the mouse, using a keyboard combination
of some kind.... with or without GOK.
Comment 5 bill.haneman 2004-09-13 14:05:53 UTC
Also Jessie:  Note that the issue you are raising above is a Mozilla issue, not
a GOK issue; this bug/ref is about GOK supporting _all_ the actions which are
exposed via the AtkAction interface.  If AtkAction for a particular UI component
has three actions, then GOK will support those three actions, via AtkAction.
Comment 6 louie zhao 2004-09-20 02:44:52 UTC
Jessie: I agree with Bill. As long as GOK supports multiple actions, mozilla can
have additional actions to accomplish the behaviour of "double click".
Comment 7 louie zhao 2004-09-20 02:54:44 UTC
How about the progress of this bug? When will it be fixed ? Thanks for feedback.
Comment 8 bill.haneman 2004-09-24 16:28:15 UTC
Created attachment 31910 [details] [review]
patch against HEAD to provide this feature

patch does not have ChangeLog entry yet.
Comment 9 bill.haneman 2004-09-24 16:55:49 UTC
Created attachment 31912 [details] [review]
slightly improved patch including ChangeLog
Comment 10 David Bolter 2004-09-24 18:27:02 UTC
Bill, nice. A couple of things:

It looks like a key could represent an action and have no label (though I'm not
sure that would ever happen with AccessibleAction_getName)

I'm confused about this check (maybe its the Friday pm factor)...
+					if (i != (action_count - 1))

What happens without that check?
Comment 11 David Bolter 2004-09-27 13:54:37 UTC
Bill, I reviewed the patch.  Looks okay.  One thing:
-    GSList *ret_nodes = nodes;
+    GSList *ret_nodes;

How about?
GSList *ret_nodes = NULL;

Please commit.
Comment 12 bill.haneman 2004-09-27 14:38:10 UTC
ret_nodes doesn't need to be initialized to NULL because it's handled in one of
the if/else clauses in the new patch, i.e. it's always set to 'nodes' or
something else.

the check for (action_count - 1) is unnecessary though harmless - because the
identical initialization will take place on re-entry into the loop in about line
2492.  Not sure if it would be good style to maintain it there anyhow, because
it does distinguish the difference between the last time through the loop, and
the previous times (when the pKeyPrevious = pKey assignment is required).
Comment 13 David Bolter 2004-10-15 15:51:41 UTC
I'm thinking we might want to roll back on this, considering the regressions
(see bug #155512).