app: [macos] improve focus #93
Conversation
|
Can you describe what this PR fixes, preferably in the commit message? |
| if w.w.d != nil { | ||
| w.w.Event(key.FocusEvent{Focus: w.focused}) | ||
| } |
There was a problem hiding this comment.
Maybe unrelated, add it as new PR?
Before that patch, Gio doesn't remove the focus from any child NSView. This patch forces Gio to get the focus when clicked. It also emit the key.FocusOp when the focus is moved to some child NSView. Signed-off-by: Inkeliz <[email protected]>
| @@ -563,6 +574,16 @@ func gio_onFocus(view C.CFTypeRef, focus C.int) { | |||
| w.SetCursor(w.cursor) | |||
| } | |||
|
|
|||
| //export gio_onResponder | |||
| func gio_onResponder(view C.CFTypeRef, first C.int) { | |||
There was a problem hiding this comment.
What about gio_onFocus, windowDidBecomeKey, windowDidResignKey? It seems to me they should be removed by this change. If not, why not?
There was a problem hiding this comment.
I think each one fits one purpose. The Responder seems to be related to the current window, and Key is global. In the end:
- If you minimize the window: the ResignKey is triggered, but resignFirstResponder is not.
- If you click in another child window: the ResignKey is not triggered, but the resignFirstResponder will be triggered.
Seems that in some conditions, both will notify.
There was a problem hiding this comment.
I think each one fits one purpose. The Responder seems to be related to the current window, and Key is global. In the end:
* If you minimize the window: the ResignKey is triggered, but resignFirstResponder is not. * If you click in another child window: the ResignKey is not triggered, but the resignFirstResponder will be triggered.Seems that in some conditions, both will notify.
So in total, Key is what we want for StageInactive, and Responder is what we want to use for focus, right?
| // That function is called when some child view becomes first responder. | ||
| w := mustView(view) | ||
| w.focused = first == 1 | ||
| if w.w.d != nil { |
There was a problem hiding this comment.
We don't check w.w.d for nil elsewhere, why here? If it's really necessary, it smells like a different problem, perhaps that SetDriver is called too late.
There was a problem hiding this comment.
Without that check it crashes. I'm not sure exactly why. I also tried to wrapper it into w.run() (the main thread stuff), and still crashing.
There was a problem hiding this comment.
What's the crash dump? Maybe we can figure out why.
There was a problem hiding this comment.
I need to check again, but that is something like: "sending events before drivers is ready".
There was a problem hiding this comment.
I thought so, which is why I commented "perhaps the SetDriver is called too late". You can try moving that call earlier, or you may have to construct a window in a two-step process: first create the window, then make it visible/key/whatever.
|
Is this relevant again? If so, what's the connection to #138, if any? |
whereswaldon
force-pushed
the
main
branch
2 times, most recently
from
f8029f2 to
026d3f9
Compare
whereswaldon
force-pushed
the
main
branch
13 times, most recently
from
3d36537 to
74ccc9c
Compare
No description provided.