GNOME Bugzilla – Bug 127862
Digits inserted at key release instead of keypress
Last modified: 2004-12-22 21:47:04 UTC
In 4.3.21, digits are inserted whenever the key is released, not when it is pressed. I type quite quickly, using ten fingers, and so far I didn't know that even if I press the keys in the correct order, I don't release them in this order. Now gcalctool told me this :-) For example if I press 1, press 2, release 2 and release 1, then all the applications I've ever met (including gcalctool 4.3.16) insert "12", but new gcalctool inserts "21". This way it is completely unusable for me. I want to type 86400, and I always get 64800 or 84600 or similar, but nearly never 86400 what I expect. I don't want to learn to type again :-)) Furthermore standard keyrepeat settings are not honoured, e.g. holding the backspaces erases extremely slowly. I've read about some a11y changes in the Changelog. I haven't set any a11y feature in Gnome. I don't really know what technically a11y means, but I do hope it's not intended to break anything by default, only add some optional features.
Adding Bill and Padraig from the GNOME accessibility team. When I fixed bug #125625 , I changed gcalctool so that it now handles "clicked" events rather than "pressed" events, so that the accessibility infrastructure works. Unfortunately now gcalctool no longer works the way that Egmont is used to. Bill, Padraig, is there a fix here that will satifsy everybody? Thanks.
Rich: without going into the source code, it looks as though the keypresses are somehow connected to the button activation, i.e. keypress/release are triggering button-down and button-up. (Otherwise I see no connection between the change in signal handlers for the gtk+ buttons, and the keyboard behavior). But this is unnecessary - i.e. it's not necessary for keypresses to be connected to the key press events, they can be handled independently of the buttons. I'd suggest the latter, i.e. decoupling the keyboard shortcuts from the GUI. It does mean that the buttons would not reflect the keyboard state whilst inputting formulae, but I don't see that as a really important feature. Alternately, if you really *must* provide visual feedback of "equivalent button clicks", you will need to do so via some other mechanism. - Bill
Created attachment 21808 [details] Proposed fix for the problem (side effect of removing visual feedback for key entered).
Thanks Bill. Egmont, I've attached a simple patch that I believe fixes this (and will still hopefully allow the accessibility infrastructure to work properly). Could you please try it out and let us know if your speed typing is working again now! Note that it has the side-effect of no longer visual toggling the equivalent button to the keyboard character that the user entered.
This patch is o.k. for me, thanks!
Thanks Egmont. Changes checked into CVS HEAD> Fixed in v4.3.22 of gcalctool. I've also just generated another tarball for the GNOME 2.5 release too.
*** Bug 128075 has been marked as a duplicate of this bug. ***