Opened 12 years ago
Last modified 10 years ago
#1317 new defect
[PATCH] [ATLAS] Atlas window steals focus on mouseover
Reported by: | Mitchell K | Owned by: | |
---|---|---|---|
Priority: | If Time Permits | Milestone: | Backlog |
Component: | Atlas editor | Keywords: | patch atlas |
Cc: | mk12360@… | Patch: |
Description
On Mac OS X Lion 10.7.3 (and other OSs ?), mousing over the Atlas window when it is not currently in focus causes it to leap to second place in the window order, so the only window covering it is the currently focused one. Seemed to be random at first until I figured out this was what it was doing.
Attachments (1)
Change History (14)
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
See ScenarioEditor.cpp
GameCanvas::HandleMouseEvent
, which calls SetFocus()
, which is presumably triggering this behaviour.
The intent is that you can click some button or textbox on the Atlas sidebar, move the mouse back over the 3D window to begin positioning a unit or brush etc, and then use the arrow key to scroll the camera around. (Without the SetFocus
, the arrow keys would get eaten by the button or textbox, and there's no way to explicitly focus the 3D window (since if you click on it to focus, you'll accidentally edit the world)).
Maybe it'd be best to restrict the SetFocus
thing to only occur if the toplevel Atlas window is already focused (i.e. there's no other application on top of it)?
follow-up: 5 comment:4 by , 12 years ago
Yes I can see that now—commenting that out does stop it from happening. The only problem is how to determine if the window is key/active/main/currently-top-focused. I tried (SDL_GetAppState & SDL_APPACTIVE) but it's not really clear what it does, and in any case it returns true when the window is not at the top. I can't find anything else.
comment:5 by , 12 years ago
Replying to mk12:
Yes I can see that now—commenting that out does stop it from happening. The only problem is how to determine if the window is key/active/main/currently-top-focused. I tried (SDL_GetAppState & SDL_APPACTIVE) but it's not really clear what it does, and in any case it returns true when the window is not at the top. I can't find anything else.
Per the SDL documentation, the SDL_APPACTIVE
flag only indicates the window is visible (not minimized) and not necessarily in focus.
I think we should use the wxWidgets API if possible, would wxWindow::FindFocus work? What does it return if the app is not focused? We could also process focus change events if there's no way to query that.
comment:6 by , 12 years ago
Keywords: | patch review added |
---|---|
Milestone: | Backlog → Alpha 10 |
Summary: | [ATLAS] Atlas window steals focus on mouseover → [PATCH] [ATLAS] Atlas window steals focus on mouseover |
Works :-) I just assumed SDL would be a level above wxWidgets and only work for this, I should have looked at wx myself.
by , 12 years ago
Attachment: | AtlasUI-Stop-Stealing-Focus(1317).patch added |
---|
comment:7 by , 12 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:9 by , 12 years ago
Keywords: | review removed |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
This breaks focus :( If a button was enabled but becomes disabled after clicking (like the simulation test buttons) then wxWindow::FindFocus()
seems to return NULL, and you can no longer control the canvas. This is reproducible on wxMSW and wxGTK. Reverting until we have a better solution.
comment:10 by , 12 years ago
Keywords: | window removed |
---|---|
Milestone: | Alpha 10 → Alpha 11 |
comment:11 by , 12 years ago
Priority: | Should Have → If Time Permits |
---|
comment:12 by , 12 years ago
Milestone: | Alpha 11 → Backlog |
---|
comment:13 by , 10 years ago
Owner: | removed |
---|---|
Status: | reopened → new |
Seems like an OS X only problem. I would guess it's a problem with SDL/wxWidgets since we don't handle focus changes directly.