1. We're using EGL most of the time anyway, so if we wanted to cache
things, we'd need to port it there.
2. Our GL handling is massively configurable, so determining when to use
the cache and when not is a challenge.
3. It makes startup nondeterministic and depend on whether a GTK4 app
has previously been started on this display and nobody thinks about
that when debugging.
4. The only benefit of the caching is delaying GL initialization - which
made sense in GTK3 where almost no app used GL but doesn't make sense
in GTK4 where almost every app uses GL.
So unless I find a big benefit to reintroducing it, this cache will be
gone for good.
Avoids having to use private data, though the benefit is somewhat
limited as we still have to put the destructor in the egl code and can't
just put it in gdk_surface_x11_finalize().
We only have one config, because we use the same Visual everywhere.
Store this config in the GdkDisplayX11 struct for easy access.
Also do this on initialize, because if creating the config fails, we
want to switch to GLX instead of failing to do GL at all.
This also simplifies a lot of code as we can share Visual, Colormap, etc
across surfaces.
There's no need to use g_object_set_data() for it.
We can also stop caching it elsewhere because we know the display has
it.
And finally, we can remove the display->have_egl boolean and use
display->egl_display != NULL instead. We initialize the display at
startup, so that variable is the perfect indicator.
We need to initialize GL to select the Visual we are going to use for
all our Windows.
As the Visual needs to be known before we know if we are even gonna use
GL later, we can't avoid initializing it.
Note that this previously happened, too. It was just hidden behind the
GdkScreen initialization.
We don't want to bind ourselves to GTK3 - both because we don't want to
accidentally cause bugs in a different codebase and because we want to
deviate from it.
While doing so, also store visuals as visuals and not as integers.
And only store one Visual because GTK4 only uses one visual.
And then remove the code that is leftover for dealing with the
compatibility Visual for GTK3.
PS: I'm kinda proud of my STRINGIFY_WITHOUT_BRACKETS hack.
The old code was ordering visuals by depth, but considering that these
days we either use the default visual or a 32bit RGBA visual, that
reordering does not have an effect anymore.
In theory, the only effect is that the GLX Visual selection might select
a different replacement Visual when it checks for improved GL Visuals, but
even there I can't come up with a case where that matters, because
again, the visuals are only reordered by depth and we want to keep the
depth.
In any case, make this a separate commit so bisecting can find this
problem if it ever shows up.
Instead of the display telling the screen to tell the visuals to tell
the display to initialize itself, just init the display directly.
What a concept.
If the pointer capability is added, pointer swipe and pinch gestures
will be created. However, if the pointer capability is removed, the
gesture objects won't be destroyed.
If the pointer capability is removed and added several times in a row,
for example due to plugging and unplugging physical mouse, this can lead
to leaking the old gesture objects.
In order to prevent that, this change makes the seat destroy swipe and
pinch gestures when the pointer capability is withdrawn.
It's only used during DND to allow use of the root window's cow window
as a DND target, because apparently gnome-shell used to think that was a
great idea to DND to the overview.
Somebody complain to gnome-shell devs about it not being a good idea if
they want it fixed.
Potentially using Wayland is a better idea though.
This reverts 85ae875dcb
Related: https://bugzilla.gnome.org/show_bug.cgi?id=601731
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
It apparently worked by chance in the past, but now causes e.g.
alphanumeric characters to be interpreted as half-width katakana
when using the Japanese IME.
We must call gdk_drag_drop_done() when the drag ends,
successfully or not. Without this, we get an unwarranted
emission of ::cancel after a successful drop.
Since only the first call to gdk_drag_drop_done() is taking
effect, it is safe to call as a fallback, after emitting
::dnd-finished. If the application connects to that signal
and calls gdk_drag_drop_done() itself, its call will take
precedence.
This matches what the X11 implementation does.
Determine the root_x and root_y coordinates of the drag surface by
relying on the coordinates of the surface where the drag is being
carried out, plus the coordinates that we receive from the drag event,
which is in-line with what the X11 backend does.
This will prevent the drag surface from being initially drawn at the
correct position, but jumping towards the top-left corner of the screen
shortly afterwards.
The DnD support will still need some more updates to function correctly
on Windows, but at least this is a small improvement.
Fixes issue #3798.
This gets the basic mechanics of the drop portion of DnD working on the
macOS backend. You can drag, for example, from TextEdit into GNOME
Text Editor when using the macOS backend.
Other content formats are supported, and match what is currently
supported by the clipboard backend as the implementation to read
from the pasteboard is shared.
Currently, we look up the GdkDrag for the new GdkDrop. However,
nothing is stashing the drag away for further lookup. More work is
needed on GdkMacosDrag for that to be doable.
We will want to be able to reuse the pasteboard reading code from
the macOS DnD drop backend. This just removes the pasteboard
bits from the implementation and allows that to be passed in as in
both clipboard and DnD cases we'll have a specific NSPasteboard
to read from.
If we are undergoing a surface move, just apply the next_layout anyways,
even if we are not moving a toplevel surface.
Update the way how we obtain the x and y coordinates of a surface, if it
is a toplevel, apply the x and y coordinates from the results from we
obtained the underlying Win32 HWND, as we did before. But if it is a
popup, use gdk_win32_surface_get_geometry() to obtain the correct x and
y coordinates to place our popup surface.
Also correct how we compute the shadow dimensions, and the final popup
rectangle as we attempt to layout the popup surface, since GDK-Win32
keeps track of the shadow dimensions in system (unscaled) units, not GDK
units.
Fixes issue #3793.
