GNOME Bugzilla – Bug 685856
osk: appear on the monitor where the focus is
Last modified: 2012-12-28 17:59:58 UTC
The on screen keyboard doesn't appear on the second monitor if that's where the login "dialog"/screen is. It should. (See https://live.gnome.org/Boston2012/Multimonitor )
Created attachment 226419 [details] [review] Layout: show the OSK on the monitor where the focused window lives In multimonitor scenarios, it makes sense to show the OSK close to the window that will actually receive keystrokes.
Review of attachment 226419 [details] [review]: ::: js/ui/keyboard.js @@ +545,3 @@ + }, + + _getFocusMonitor: function() { We already have simlar methods in layout.js ... we should reuse them and not re implement them here. like chrome._findMonitorForWindow (make it public) and findMonitorForActor
Created attachment 226503 [details] [review] Layout: show the OSK on the monitor where the focused window lives In multimonitor scenarios, it makes sense to show the OSK close to the window that will actually receive keystrokes.
would be nice to get this in - pretty basic multi-monitor functionality
Giovanni, the patch isn't really complete yet, right? Anyway I'm looking into this now, please do yell if I'm stepping on your toes :-)
It's not complete because it's not tested and thus probably buggy, but the code is that.
Created attachment 229369 [details] [review] OSK multi-monitor fixes -- The patch here looks generally fine but needs a few fixes on top. Giovanni can you look over these fixes and squash it with your patch if you agree with them? Note that we need to be able to set the monitor separately from showKeyboard() because _redraw() needs to know the monitor to properly draw the OSK.
Created attachment 229372 [details] [review] keyboard: Show in an idle on clutter key focus changes It's common to do actor.grab_key_focus() before the actor is mapped which means that we can't reliably determine where the actor is at notify::key-focus time and thus might end up showing the keyboard on the wrong monitor. This is happening, in particular, with the run dialog. Delaying until we hit the main loop allows us to know where the actor finally is before showing the OSK.
Created attachment 229483 [details] [review] Layout: show the OSK on the monitor where the focused window lives In multimonitor scenarios, it makes sense to show the OSK close to the window that will actually receive keystrokes. The fixes made sense, so I squashed them as asked.
Review of attachment 229483 [details] [review]: Thanks, looks good.
Comment on attachment 229483 [details] [review] Layout: show the OSK on the monitor where the focused window lives Attachment 229483 [details] pushed as 8a7c031 - Layout: show the OSK on the monitor where the focused window lives
Review of attachment 229372 [details] [review]: Uhm, I guess I could review this one, having written the other half... ::: js/ui/keyboard.js @@ +283,3 @@ + this._clearShowIdle(); + this._showIdleId = GLib.idle_add(GLib.PRIORITY_DEFAULT_IDLE, + Lang.bind(this, function() { this.Show(time); })); It would be better to check if _showIdleId != 0, and not add the idle in that case, as remove and adding idles is not free.
Created attachment 230508 [details] [review] keyboard: Show in an idle on clutter key focus changes -- (In reply to comment #12) > It would be better to check if _showIdleId != 0, and not add the idle in that > case, as remove and adding idles is not free. Fixed. Thanks
Review of attachment 230508 [details] [review]: Yes.
Should we land this ?
Attachment 230508 [details] pushed as f07fee5 - keyboard: Show in an idle on clutter key focus changes