Merge lp:~mterry/unity-greeter/focus-main-window-on-unmap into lp:unity-greeter
Status: | Merged |
---|---|
Approved by: | Robert Ancell |
Approved revision: | 577 |
Merged at revision: | 604 |
Proposed branch: | lp:~mterry/unity-greeter/focus-main-window-on-unmap |
Merge into: | lp:unity-greeter |
Diff against target: |
41 lines (+24/-1) 1 file modified
src/unity-greeter.vala (+24/-1) |
To merge this branch: | bzr merge lp:~mterry/unity-greeter/focus-main-window-on-unmap |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Unity Greeter Development Team | Pending | ||
Review via email: mp+124544@code.launchpad.net |
Description of the change
Currently, if you open a dialog like the Switch Off one, then close it, you lose the focus-styling around the user list's entry box (though keyboard presses still go to it).
Calling main_window.
But how to tell when to do that? After every Unmap seems extreme. And ideally we'd only do it in cases where the user list is receiving keyboard presses but not focused (this weird halfway-focus GTK is giving us). As far as GTK/GDK/X are concerned, the window doesn't seem to have the focus in that state.
The closest I came is asking X directly, what has the focus. In this state, it gives back an odd pointer value like 0xaf and a revert_to value of X.RevertTo.None. So I'm using the revert_to value as a key that no other window has a claim to the focus.
This branch seems to work for me, but it feels a little black magicky.