GNOME Bugzilla – Bug 155556
gok ui grab keys can branch-to/invoke actions but shouldn't ignore children of actionables.
Last modified: 2004-12-22 21:47:04 UTC
If UI grab a component which has an action interface, it just list all its actions. Its children won't be shown. In the past, it will list all the children instead of the actions.
This bug is significant. I will investigate.
The report isn't quite accurate, I think. In the past, GOK preferentially invoked a child's action instead of a parent's action, if the object in the UI Grab had an actionable child. That logic is still present, but if the parent has more than one action available, the above shortcut can't be taken; instead GOK must list the child actions among the parent actions (if actionable_child_count >= 1). Seems that perhaps the creation of the 'Actions' keyboard is failing to include the actionable children's actions.
What is a good test case for this?
Another finding today: Even all the parent actions are listed there, clicking any of them actually always invokes the first action.
Harry thanks for the reporting. I need more detail to get any useful understanding. Can you provide steps to recreate the behaviours you mention, as well as descriptions of the behavour?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
comments from Bill: Harry: I believe you may be mistaken about GOK presenting all the children of an Action-implementing container. To the best of my knowledge GOK never did this for the general case. There was a bug which caused GOK to ignore the Action interface in some situations. At the same time GOK had some simplified logic which caused it to invoke a child action on an actionable component in preference to the parent's action, if one was present - but this simplified logic only worked for the '0'th or default action. That behavior was responsible for other bugs/problems, so it had to change, and in order to support multiple actions (an urgent request of the Evolution and Mozilla teams), the other simplified action logic also had to be changed. I agree that GOK should present child actions to the end-user, but this requires new code to be written, it isn't a logic error in the new checkins. - Bill
In JDS' evolution, we have a customed component which has a action interface and some actionable children. In old GOK (before Oct. I think), UI grab can see this component. When grabbing it, GOK just lists all the actionable children. In current GOK, when grabbing it, GOK just lists all its action. Its children won't be shown. If I remove the action interface, GOK's UI grab won't list this component in the GUI. GOK lists its children directly. If GOK can list both the component's action and all its actionable children, that would be more useful. Another problem is though GOK lists all its action, clicking any of them just invokes the component's first action (the default action?). For example, you can UI grab a gtk button. In the past, GOK invokes the default action ("click")directly. Currently, GOK will list the button's 3 actions, "click", "press" and "release". But clicking any of the actions will invoke "click" action.
Harry: I am filing the 'all actions are default action' bug as a separate issue.
(11:21:30) davidb: i'm not active on it. i think it is valid. we probably need to prefix actions with the name of the component, or add some heirarchy. (11:21:39) davidb: and expose the children (11:22:17) billh#sun: just adding the child actions should be OK in most cases 11:22 (11:22:47) davidb: by "child actions" are we talking really talking about "child components"? (11:23:28) davidb: so we would have a keyboard with actions (of the parent) and names (of the chidlren) (11:23:42) billh#sun: potentially quite messy (11:24:07) davidb: yes. so perhaps on the actions keyboard, a key to branch to actionable children? (11:24:17) billh#sun: probably the issue was being masked by an old GOK bug that was causing the container's actions to be missed (11:24:23) billh#sun: hmm (11:24:29) billh#sun: sounds not-so-good (11:24:36) billh#sun: (branch to actionable children) (11:24:40) davidb: too much indrection. (11:24:46) billh#sun: yes (11:24:54) davidb: so prefix the actions with the parent name? (11:25:02) billh#sun: I would think parent actions and actionable-child-keys (11:25:19) billh#sun: i.e. looks like the UI Grab keyboard, but starting at a different root (11:25:29) davidb: sure. (11:25:44) davidb: but we've never had a keyboard with actions and components (names) (11:25:52) billh#sun: yes, perhaps prefixing with the parent name, but only if there are actionable children (11:25:57) davidb: right (11:26:02) billh#sun: (otherwise, needless verbosity and reduced readability IMO) (11:26:16) davidb: yes. (11:26:18) billh#sun: I think we have, more or less (11:26:54) billh#sun: we've had UI Grab which includes actionable things _and_ not-really-an-action things (like text fields, the back button, scrollbar buttons, etc.) 11:27 (11:28:00) billh#sun: OK, well perhaps this one will have to wait a couple more days. (11:28:07) davidb: i think so.
Created attachment 33315 [details] [review] proposed patch I can't test this as I don't have a test case.
Hi I have patched it. But GOK crashed when I use it to grab the calender and then the day view. I commented out the SIGSEGV handler and used GDB to get the trace as follows: --------------------------------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault.
+ Trace 51566
Thread 1024 (LWP 21950)
The stack trace helps a lot thanks! I can see that I am calling AccessibleStateSet_unref 1 many times, but I am surprised that would cause a SEG. Perhaps that is not the cause. I'll attach an improved patch.
Created attachment 33348 [details] [review] proposed patch v2 Meng-Jie, I hope this avoids the seg fault.
double unrefs mean double frees, and SEGVs often result.
Good to know. Too bad there is no safeguard against that.
The patch works. GOK no longer crash. However, there is another problem. In general, as the GOK's working mechanism. when a button is pressed using GOK, GOK will give out three action, Press, Click and Release. Let the user to choose the action they want. Nevertheless, When I press some buttons of Evolution, GOK seems not give out the three actions. Instead, GOK do the default action (often the click). while some cb function is not connected to the default signal (action), therefore, it can not call the callback functions using GOK. I wonder why GOK don't give out three actions to any button ??
Meng-Jie, the (unwanted?) behaviour you describe might be the result of an intentional "fix" (see bug 154604). Do you see a situation where the three actions: click, press, release need to be shown? Also, does the latest patch fix the initial problem? (I guess I should ask Harry?)
David, yes, the patch fix the initial problem from our testing. Thanks. For bug 154604, I have some concerns here. As I can see from some codes, not everyone connect to the "clicked" signal of a gtkbutton. Some just connect to the "pressed" signal, and in some cases, they connect to "button_press_event" signal. So their signal handling function won't be called when you just let the button emit a "clicked" signal. In gailbutton.c, the action "press" will simulate a button press event. So their function can be called when doing the action "press". So I think leave the 3 actions there, user can try "click" first, if this doesn't work, he might then try "press".
Harry I'll respond over in bug 154604. Thanks for testing the patch. Bill can you give it a once over before I commit?
I think exposing only "click" is OK if click is the first of 3 actions. For the cases we know about, "press" is the first action for things that connect to the button-press/release signals. The alternative, always showing all 3 actions, causes a problem because it requires a whole new choice from the GOK user, and for switch users this can represent a serious efficiency loss.
NOTE: bug 157358 has been created for this discussion tangent.
Comment on attachment 33348 [details] [review] proposed patch v2 commit with small change - please remove the "if (did_actionkeys) block" as it does nothing (as we discussed on IRC)
Created attachment 33428 [details] [review] proposed patch v3
Comment on attachment 33428 [details] [review] proposed patch v3 patch as committed.
Fixed in CVS. Thanks everyone!