GNOME Bugzilla – Bug 162998
Calculator register options not working correctly with GOK
Last modified: 2005-03-29 15:36:01 UTC
With Cinnabar Build_25 : -Launch GOK (Dwell mode with 2nd mouse) -Launch Calculator -Enter some value in Calculator -UI Grab the Calculator, and select 'Store to register' option -Notice GOK does not handle these drop down buttons correctly -It does not allow a user to store or recall values
Bugster bug #6214176
Thanks Frances, do you know what role the drop down window has? -- And the "buttons"? Also I am curious if/how at-poke picks it up.
The Store drop down "button" stores values in the calculator (up to 9 numbers) The Recall "button" allows you to get any stored numbers With at-poke, these buttons are treated the same as the numeric buttons, and not shown as drop down menus.
I believe David might have been referring to the atk "role". GOK sees these as buttons too, but clearly there are other differences in their AtkAction or other ATK interfaces - does at-poke show something other than 'click' for the first AtkAction? Does it expose children of the button? etc.?
at-poke shows 'click' for the first AtkAction : click press release It does not expose any children of the button
Thanks Frances; then the question for David and myself is, why doesn't our logic for catching popup menus react appropriately when the drop down list is posted?
I'll take a look.
Frances, can you expand on the initial report item: "Notice GOK does not handle these drop down buttons correctly" Is the popup menu appearing? Does the GOK keyboard change to show the menu items? What exactly is the behaviour you are seeing?
I believe that gnome-calculator is not implementing the click action properly... that is must use a different code path. Frances, can you confirm the behaviour of activating "click" on "Rcl" using at-poke (use keyboard to select "take action") simply puts "Rcl" in the display area - which to me is a weird thing to do!
David, the popup menu does not appear when using gcalctool with GOK. When I activate any of the register buttons with GOK, they just grab focus and then do nothing. No popup menus or list of register options are shown. Clicking on "Rcl" Take action using at-poke also does nothing. It does not store any values from the calculator display window
this is a calculator bug, at heart - because the "default action" for these buttons is 'click', which does nothing ('press' is the action which actually does something). Because it is not possible for the accessibility system via gtk+ or gail to know, beforehand, whether there are user-visible actions associated with the AtkActions which are exposed, we cannot tell (either in GOK or in gail/atk) which actions are 'interesting' enough to show the user. GtkButtons generally have three actions associated with them - click, press, release. Of these, in 90% of cases, only the first one is useful. For this reason, when GOK sees the exact pattern "3 actions, called click, press, release", it does NOT present a three action menu to the user. For such GtkButtons, either the application should register its signal handler for the 'click' action, or it should override the AtkActions so that either only one action is exposed, or the first action is the correct useful default. This is the way other applications deal with this situation. In the case of gcalctool, it's actually not clear why press and release are used instead of click, as a quick 'click' gesture (press release in quick succession) result in the desired behavior. It seems that there may be some timer-based behavior here, which would of course also be an additional accessibility bug (UI elements should not be time dependent).
The problem is easy to see using at-poke. Because GOK recognizes and reduces the 3-action 'click, press, release' case to one action, and in so doing vastly improves the productivity of GOK users for the majority of gtk+ apps, the best fix is to modify gcalctool so that either: 1) the default 'click' action causes the drop-down list to post; or 2) the AtkActions reported no longer match the 3-action 'click,press,release' pattern. Just changing the order in which the actions are reported would be sufficient. - Bill
Modifying the menu buttons to used "clicked" instead of "button-press-event" will mean the menu will only appear when the mouse button is released or a timeout has occured, which is not the way it currently works. How do I adjust the gcalctool code to try the second suggested fix above?
Created attachment 36352 [details] Patch to change the "menu" button "button-press-event" event to "clicked" Actually, it feels just fine. From a UI prespective I'm happy with this attached change (to CVS HEAD). Does it make gok do the right thing (I don't have a copy of the latest complete stack - just glib/atk/pango/gtk+ and gcalctool).
Doing #2 is considerably more work - you'd have to subclass GtkButton here, and provide an inherited AtkObject type that replaced the default AtkAction methods. I'll try the patch when time permits - but using the 'clicked' event should be all that's necessary.
Fair enough. As I want to generate a new tarball on Monday for the GNOME 2.10 "call for tarballs", I've gone ahead and checked this fix into CVS HEAD. I've bumped the version number in configure.in to 5.5.28. If this doesn't fix the problem, please just go ahead and reopen the bug and I'll investigate further.
Thanks a lot Rich! I'm glad the easy fix worked out.
fix apparently causes SEGV.
Created attachment 39388 [details] Correct fix for this problem. As reported in CR ##6214176, there is a new fix for this problem that "works for me". I've already applied this fix to gcalctool CVS HEAD too.
Closing as FIXED. If this proves not to be the case for you, then feel free to re-re-open.