Fix project manager stealing focus on i3

[dsnopek]

Fixes #95824

TL;DR: This fix isn't ideal, but I think it's probably OK.

Here's what's going on in detail:

• In LineEdit, on NOTIFICATION_DRAW (which happens every time the cursor blinks), if the LineEdit is focused, it will call DisplayServer::window_set_ime_active() which will grab focus for the window the LineEdit is in
• Since Control::has_focus() only checks if the control is focused according to Godot and doesn't check if the window is focused, this can steal focus back to Godot as soon as the cursor blinks again
• So, this PR adds a check to DisplayServer::window_is_focused()
• Unfortunately, this on its own doesn't fix the issue, because we're using the X11 FocusOut event to mark a window as not focused, and these events come in asynchronously, creating a race condition. What happens is focus switches away from the project manager window, but before the FocusOut event is received, LineEdit's cursor blinks and it still thinks it's window is focused
• So, this PR also changes DisplayServer::window_is_focused() to do a synchronous check to see if the window is really focused right now

This isn't ideal for a couple reasons:

1. It's ignoring the WindowData::focused flag (which we update in response to the X11 FocusIn and FocusOut events) which is used in a whole bunch of other places. However, I think this is OK, because those other places don't seem to be sensitive to similar race conditions, and it sort of makes sense that if we call DisplayServer::window_is_focused() then we probably want the most up-to-date data.
2. The fix isn't contained to display_server_x11.cpp, it has ventured into the LineEdit and TextEdit nodes. But the only possible fix that I could come up with entirely within display_server_x11.cpp would be to revert PR Fix text editor stealing focus from "Find in Files" dialog on X11 #93682, but that would cause problems with Gnome and KDE. However, I think this fix is OK, because the whole idea of grabbing focus in NOTIFICATION_DRAW seems a little problematic in the first place - adding some extra protections around that makes sense to me.

Please let me know what you think!

[Rindbee]

I tested this PR and confirmed that it fixes #95824; however, when using F1 to open the Search Help popup, the search bar no longer automatically gets focus.

[dsnopek]

however, when using F1 to open the Search Help popup, the search bar no longer automatically gets focus.

Hm. I'm able to reproduce this, but only if the code editor is what is focused when I press F1. If the 2D or 3D viewport is showing, it works fine. I think perhaps the CodeEdit control has a similar issue to LineEdit? I'll look into it.

[dsnopek]

My latest push adds the same fix to TextEdit (the parent of CodeEdit) as well, which fixes the issue for me. Please let me know if that works for you, and/or if you notice any other issues :-)

[Rindbee]

The latest modification solved this issue for me as well.

[akien-mga]

Should we update wd.focused accordingly after doing this synchronous check?

[dsnopek]

My personal inclination would be not to update wd.focused here.

There's a bunch of other state that changes when the FocusIn and FocusOut events are received, and unless we're going to also run all of that, I don't want to just change wd.focused, which could lead to the internal state of DisplayServerX11 being temporarily inconsistent (temporary, because everything else will get changed when the event finally comes in).

But if other folks who are more expert in this code (ex @bruvzg) think it would be better to update wd.focused here, I'd be happy to defer to their judgement and update the PR :-)

[akien-mga]

Thanks!