Keep the editor help search dialog inside the screen

[trollodel]

Fixes #79187 as described here

I can't test the conditions described in #79187, so testing appreciated.

[Sauermann]

This might get made redundant by #79698 or #79617, both of which attempt to solve the inside-screen-problem for all windows and not just EditorHelpSearch.

[trollodel]

I talked about that possibility here, but I didn't know that there are already PRs to fix it. Surely better than this PR.

[YuriSizov]

I don't entirely understand why having a different size would be a problem to begin with. Windows can exceed resolution bounds just fine. While the usability of such windows can be questioned, there shouldn't be a crash/freeze/other negative side effects. So that's one problem.

Another is why in case of #79187 the dialog appears on a wrong display to begin with. Was it placed there previously? Is it restored improperly? Do we also need to store the display index alongside the window rect? To be honest, I don't quite understand the steps from the OP and I don't have a second display to experiment myself. So if anyone could explain what's going on from the user perspective, I'd appreciate it.

What I can say for certain is that we indeed shouldn't fix this just for the editor help dialog. We should fix it for every dialog whose dialog_bounds we store and restore. We should unify the code responsible for restoring somewhere on EditorInterface and fix the issue there. I'm not entirely sure how a solution can be extended to Window itself, though, as the problems above do not appear that general to me. But if some helper method or setting can be added to Window, then by all means. I don't think it's #79617 though.

[trollodel]

This is a general problem with multiple windows and multiple screens. Often, the editor code that manages window and size assumes implicitly that there is only one window and that the positioning and screen size doesn't change. This was guaranteed until 4.1.
This PR fixes some (but not all) scenarios when the user's screens layout changes, and only in one place. In the specific case, the bound goes out of screen because the screen was resized, but Godot doesn't know about that and tries to place in the old configuration.

What I can say for certain is that we indeed shouldn't fix this just for the editor help dialog. We should fix it for every dialog whose dialog_bounds we store and restore. We should unify the code responsible for restoring somewhere on EditorInterface and fix the issue there. I'm not entirely sure how a solution can be extended to Window itself, though, as the problems above do not appear that general to me.

This is true, code editors and docks do have a centralized and more complex fallbacks (in WindowWrapper) in case the screen layout changes, that can be made more generalized if desired.

Windows can exceed resolution bounds just fine.

No, it's not fine. If a resolution change put the window out of screen, and the window is modal, you can't recover your editor.

[YuriSizov]

No, it's not fine.

Windows exceeding resolution in size is fine. Windows moving out of the visible space completely is not fine. I was referring to the former.

This PR fixes some (but not all) scenarios when the user's screens layout changes, and only in one place. In the specific case, the bound goes out of screen because the screen was resized, but Godot doesn't know about that and tries to place in the old configuration.

This doesn't explain a freeze that the user describes, since on their screenshots the help window is still visible and thus the editor is recoverable. Still, I think all restorable dialogs like that should be fixed together and anchored to their contextually relevant parent windows rather than arbitrary places on screen.

[akien-mga]

Superseded by #79617.

[akien-mga]

Superseded by #79617.

Or maybe not, based on #79187 (comment).