GNOME Bugzilla – Bug 674955
umlaut popup does not work
Last modified: 2013-01-04 13:16:08 UTC
Hi, when I'm entering an umlaut symbol like Ä (by holding the A-button a second and click the Ä in the popup) the keyboard minimises when the "subchar"-window closes. The desired char can be entered, but its not very comfortable to restore the keyboard after every special character. This was not the case in Gnome 3.2 by the way. Thanks!
Created attachment 221970 [details] [review] keyboard: prevent focus lose when extended keys are hidden "key-focus-changed" handler assumes that a key actor keeps focus until the extended keys boxpointer is hidden. However, popModal in Key._ungrab resets the focus to the stage, and thus the entire keyboard is hidden after key press. This patch makes sure to set the key focus to the trigger key actor before pushModal.
while fixing the umlaut popup, we should keep in mind that we may want to reuse it for https://live.gnome.org/GnomeOS/Design/Whiteboards/ExtraCharacters
Created attachment 229373 [details] [review] keyboard: Fix subkeys handling We can't pushModal() when showing the subkeys popup because that will cause the application to lose focus and thus we get a Hide() call for the whole OSK. Instead, capture events on the main OSK actor while the subkeys popup is shown so that we can both prevent events from reaching the main keys but also cancel the subkeys if the user clicks away in the the OSK.
Created attachment 229374 [details] [review] keyboard: Don't set keys as checked There's no reason to do it and it actually breaks when showing subkeys since then we won't get a 'key-released' signal for the main key.
Review of attachment 229374 [details] [review]: OK.
Review of attachment 229373 [details] [review]: Yikes, this is a bit messy. ::: js/ui/keyboard.js @@ +318,3 @@ + + if (!press && !release) + return true; This will be handled implicitly by below. @@ +331,3 @@ + if (hoveredActor._delegate && + hoveredActor._delegate instanceof Key) { + hoveredActor.set_hover(true); sync_hover? @@ +368,3 @@ + if (this._subkeysBoxPointer) { + if (this._subkeysBoxPointer == button.subkeys) + return; Could this realistically happen? @@ +379,3 @@ + button.connect('hide-subkeys', Lang.bind(this, function() { + if (this._subkeysBoxPointer != button.subkeys) + return; Could this realistically happen?
Created attachment 232075 [details] [review] keyboard: Fix subkeys handling -- (In reply to comment #6) > Review of attachment 229373 [details] [review]: > @@ +331,3 @@ > + if (hoveredActor._delegate && > + hoveredActor._delegate instanceof Key) { > + hoveredActor.set_hover(true); > > sync_hover? As we discussed on IRC, this is about the actor over which the pointer is when the popup goes down, which might or might not be the one from where the popup originates. We agreed on IRC that we need something like a shell_global_sync_hover() to handle this correctly everywhere so I'm removing these bits from this patch and keeping it strictly about the OSK subkeys functionality. We'll handle the hover in another bug. I removed the other unneeded conditions you pointed.
Review of attachment 232075 [details] [review]: OK.
Attachment 229374 [details] pushed as 6255c77 - keyboard: Don't set keys as checked Attachment 232075 [details] pushed as c33622f - keyboard: Fix subkeys handling