GNOME Bugzilla – Bug 108209
Animate buttons when using keyboard
Last modified: 2004-12-22 21:47:04 UTC
If the user types numbers etc. using the keyboard, it'd be cute if the button animated. This will happen automatically if when you get the key event, you gtk_widget_activate the button, which will then emit "clicked" on the button and indirectly insert the text.
Heh. This functionality was in the original calctool (OpenWindows DeskSet circa 1992) that gcalctool is based on. It would be fairly easy to add it back in. Cc:'ing Calum for his take on this, as it's a UI issue.
Yes, that sounds like a good idea. All buttons should do this really, and in most other dialogs/apps they already do.
Created attachment 15011 [details] [review] Proposed patch.
Hi Rich, This looks like an easy one. I attached a small patch to connect the activate signals in create_kdb_accel(). -- Dennis
shouldn't you replace "clicked" with "activate" instead of having both? (maybe I'm missing context)
Adding Dennis to the CC: line so he can see Havoc's last comment, and tell whether it's appropriate (and simplifies the solution). Thanks.
Yes, replacing "clicked" with "activate" in a single gtk_widget_add_accelerator() call implemented this "feature". Fix adjusted accordingly. Fixed in v4.2.68 of gcalctool. Thanks Havoc/Dennis.
Rich, The animation does not work for the numeric keypad (on Linux). I will attach a patch to fix this very shortly.
Created attachment 15040 [details] [review] Fix for numeric keypad (Linux).
Thanks Dennis. Patch added (and verified on my RH8.0 system at home). Fixed (again) in v4.2.71.
This functionality seems to have disappeared again from the latest gcalctool. Reopening, pending further investigation when I return to work on 9th June.
This problem has resurfaced because of the change that was made on 2003-04-24 * Fixed bug 111269 (http://bugzilla.gnome.org/show_bug.cgi?id=111269) It was possible to type fast into gcalctool and digits would be transposed. gcalctool now looks for key_press_event and key_release_event events on the main window rather than set keyboard accelerators to the "clicked" action of the various buttons. A similar fix to the one already attached will have to be created for the new paradigm. More when I return, unless Dennis beats me to it.
Hmm, I wonder what the root cause of the transposing was - the main loop reordering timeouts unexpectedly? Is "clicked" only emitted after the animation timeout ends? Sounds like it's kind of dubious behavior on GTK's part.
"clicked" is indeed emitted only after the animation ends ... think of buttons on a dialog - if you emit the signal instantly, you don't see the animation. (And it just feels wrong)
So if the timeouts expire in the same mainloop iteration, perhaps there's no ordering guarantee (sound plausible?)
If you end up in the timeout paths, there certainly will be no ordering guarantees. Though if you end up in the timeout paths, the feel is going to be horrid anyways; the timeout is pretty long; it's supposed to be happening on key release in the normal case.
Maybe the explanation is simpler then - pressing the next key prior to releasing the previous key.
Hi Rich, I hope all is well. I finally had the chance to look at this bug. I am attaching a small patch for consideration. It works on Linux. You should test it on Solaris. -- Dennis
Created attachment 17472 [details] [review] A proposed patch.
Created attachment 17476 [details] [review] Same patch but connects to the 'pressed' signal.
Thanks Dennis! I've been doing my impersonation of a demo dolly at JavaOne for the last three days so you've saved me a bit of work. Fixed in v4.2.88.
I updated to version 4.3.50 this morning, and this bug has returned. Was this intentional? It's been quite sometime since I last updated, but I know it worked correctly in version 4.3.3.
Unfortunately in order to fix bug #127862, which was needed so the accessibility infrastructure would work correctly, we've now lost the ability for gcalctool to animate the buttons. I was unsure exactly which category to choose for closing this. WONTFIX isn't right because I'd really like to have this feature. Unfortunately Gtk+ doesn't seem to have the ability to do this with the way the keyboard event handling is now done. NOTABUG is not quite correct as this really is useful functionality. Bugzilla doesn't have a CANTFIX, so I've ended up having to go with NOTABUG. If somebody can think of a way of providing this functionality and allowing the accessibility stuff to do their thang, please reopen and attach a patch. Thanks.
I feel like I'm missing something - in any gtk program activating a button via mnemonic will animate it. What is different in the gcalctool case? I think this bug should be moved to gtk perhaps with a clear exposition of new GTK api to be added, if it's not possible to fix in gcalctool, rather than closing it.
Okay, I can do that. Owen, over to you.
I'm going to mark this as a duplicate of another bug about ordering when pressing a bunch of animated buttons quickly, since if I remember, that's why the calculator moved away from using normal mnemonics. *** This bug has been marked as a duplicate of 127480 ***