New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't bring appearing host window to front unless any of the contained… #7116
base: docking
Are you sure you want to change the base?
Don't bring appearing host window to front unless any of the contained… #7116
Conversation
…d windows require initial focus
Thanks for the PR! |
I haven't familiarized myself with the test suite yet, but yes, exhaustive automatic testing would be good. I will give it a try when possible, but can't promise anything soon. I thought I did pretty exhaustive manual testing, but it turns out I missed a case. Or a few cases when docking already existing windows together. Then there are no appearing windows except for the host window, which doesn't get brought to the display front. In most cases this looks fine, but technically the order is wrong. And in the case where window A is partially overlapped by B, then C gets manually docked into A, then C has focus but is still overlapped by B. I could just bring the host window to the front if none of the windows are appearing, but that would exclude complex cases where windows are being docked while new ones are appearing. And I like the idea of not loosing the current topmost window if two other non-topmost windows get docked together programmatically. So I just tested the combined criteria of any appearing window wanting focus or (that's the addition) any contained window having been the previous topmost window, then the host window should be brought to the front. So far this seems to work as desired, but I need to do a bit more testing to be sure. I will update tomorrow. |
I pushed an update after quite extensive testing. It is still rather simple, but handles all of the cases now:
Now this improved solution handles all of the cases in a neat way. No fully automatic test case yet, but I did a lot of manual testing (appearing windows, docking entirely manual, docking with code in all variations). And the complexity of the change is so low that all possible paths can be verified. |
… windows require initial focus
I took a closer look at how to implement the "officially" suggested fix for one of the problems in #7008, specifically this one:
The fix was surprisingly easy since all of the needed information is available right there. If the host window is appearing, instead of just bringing it to the front, it now checks its contained appearing windows first and is brought to the front only if one (or more) of the contained appearing windows has
ImGuiWindowFlags_NoFocusOnAppearing
not set (thus requiring initial focus).This fix makes the behavior of appearing windows consistent regardless of how they may be docked. Here are some GIFs of the before and after behavior. Ctrl+Click is custom functionality through wrappers (no library change) for "sticky" menu items. They keep the menu open while appearing windows get the
ImGuiWindowFlags_NoFocusOnAppearing
flag.Normal click closes the menu and opens the window without the flag, the behavior is not changed by the fix:
Ctrl+Click keeps the menu open, window gets the flag, but host window gets brought to the front anyway without the fix:
Ctrl+Click with the fix results in the desired behavior: