Make Drag and Drop an application-wide operation.
This allows do drop on Controls in other Viewports/Windows.
In order to achieve this, `Viewport::_update_mouse_over` is adjusted to
remember the Control, that the mouse is over (possibly within nested
viewports). This Control is used as a basis for the Drop-operation, which
replaces the previous algorithm, which was only aware of the topmost
Viewport.
Also now all nodes in the SceneTree are notified about the Drag and Drop
operation, with the exception of SubViewports that are not children of
SubViewportContainers.
Before, they would always complain even if there was no attempt at
initializing them (e.g. because there's no X11 display).
While we're at it, this patch also adds a specific message for OpenGL ES
and rewords "OpenGLES" to "OpenGL ES" in an error, for consistency
(AFAIK we either say "GLES" or "OpenGL ES").
On Windows this allows to avoid having to change the owner of the window
after it has been created, which in rare circumstances may cause the
window to bug out.
Allocated XImages are improperly free'd with XFree.
The X11 documentation says that XImage should use
XDestroyImage to free both the image structure and
the data pointed to by the image structure.
Also fix a potential use-after-free bug.
Input events go to the tooltip because it's added to `popup_list` in
DisplayServer `popup_open`. I think there's no harm in tooltips being omitted
from the list, so this commit blocks non-popup windows from being added if they
have `FLAG_NO_FOCUS` and `FLAG_MOUSE_PASSTHROUGH`.
I'm not happy with this way of detecting tooltips. It'll also catch other
windows where this behavior may or may not be wanted.
I thought about adding `FLAG_TOOLTIP`, but went with the smaller change for
now.
Fixes#79500.
usleep(3) was declared obsolete in POSIX.1-2001 and removed in POSIX.1-2008.
nanosleep(2) was recommended to be used instead.
`OS::delay_usec()` internally uses `nanosleep()`.
This also uses large number separators for improved readability.
This is a workaround for the most critical portion of the WM focus bug
described in #68305. On some specific X11 WM configurations, the
editor's main window and any popups it creates will fight for focus,
which causes a total system lockup due to mouse and keyboard input being
stolen as well. Getting out of this infinite loop requires force
restarting the system.
It can be tested with the following shell script:
```bash
!#/bin/sh
godot4 &
sleep 30
pkill -x godot4
```
The workaround identified in #68305 is to remove the call to
XSetInputFocus in the ConfigureNotify event handler, so I have removed
the conditional block that calls this as well as the setup code above it
since there is no need to allocate the memory for the variables if they
won't be used in that call anymore.
This is just a hack and is not a complete fix for #68305. Multiple
developers are collaborating on a proper fix in the discussion in that
issue, but time is a valuable resource that no one has enough of, so I
am committing this workaround as a stop-gap to prevent the most critical
problem while we work on a full solution for the underlying cause.
This adds a new enum `KeyLocation` and associated property
`InputEventKey.location`, which indicates the left/right location of key
events which may come from one of two physical keys, eg. Shift, Ctrl.
It also adds simulation of missing Shift KEYUP events for Windows.
When multiple Shifts are held down at the same time, Windows natively
only sends a KEYUP for the last one to be released.
