Instead, use [Set|Get]WindowLongPtr(), to store and retrieve that
value from the notification window HWND that we are using, as it
is where we are using that value.
Tuck the _win32_device_manager global variable into GdkWin32Display, and
drop the global variables that have to do with GdkDeviceManagerWin32.
Also improve how we query the WinPointer APIs from user32.dll, so that
we are sure that it is done once and only once.
Tuck the GdkWin32Clipdrop that we create in our GdkWin32Display, and
tuck the other associated global variables into GdkWin32ClipDrop and
GdkWin32Drag, as appropriate.
Also, since we are already registering "GDK_WORKER_THREAD_WAKEUP" as our
custom message to look for in our DND/clipboard ops, only register it
once, not twice, as it's not really necessary to do so since
RegisterWindowMessage() returns the same value for the same identifier
that is being used.,
Instead, record the current thread in the GdkDisplay, under a structure
for DND items, which will hold other relevant Windows Clipbord/DND global
variables.
Add a new function in gdkdrag-win32.c to check whether the current
thread is (or is not) equivilant to the thread that is initiated when
the GdkDisplay is initialized (which also returns true if there is no
GdkDisplay that is associated with the GdkDrag in question).
Rename gdkwin32id.c as gdkwin32misc.c.
Fold these items into GdkWin32Display, and also fold gdkproperty-win32.c
and gdkwin32langnoticiation.[c|h] into gdkwin32misc.c and gdkdisplay-win32.h as
appropriate.
This way, we get rid of few more global variables, and these items
should have been initialized (and registered with the system) when we
open a GdkWin32Display anyways.
Use the gdk_win32_surface_parent_class that is given to us by
G_DEFINE_TYPE() instead of using a global variable to store up the
parent class of GdkWin32Surface.
Since cairos gradient code isn't flexible enough to let us
interpolate in oklch, add additional color stops and let cairo
interpolate in the ccs. This isn't as accurate as interpolating
in oklch, but it gets an ok result for fallback situations.
Make all our gradient ops adjust the hue according to
the hue interpolation.
This is currently modifying the values in the vertex array.
If reading those values back is bad, we may need to change that.
If the interpolation color state is not a default one, use the
offscreen we already for rendering big gradients, interpolate
the gradient into it, and then use a cicp convert shader to
convert the result to the ccs.
Pass the ccs, opacity, interpolation color state and hue
interpolation explicitly, and change the argument order to
match other ops.
Since we now apply opacity in the op, change the node processor
to pass colors as-is. For now, it always passes GDK_COLOR_STATE_SRGB
for ics and GSK_HUE_INTERPOLATION_SHORTER for hue interpolation.
It is nicer if gsk_gpu_color_states_create_explicit (a, a) works
regardless of whether the two are default colorstates or not.
The gradient shaders will rely on this when the ics is a non-default
color state and we use ccs == ics.
The original intent was to only realize parents recursively for
non-widget accessible objects. The implementation, however, always
try to realize parents. In the case of GtkStackPage, which is a
non-widget accessible with a widget accessible child, this breaks.
Only realize non-widget accessible parents recursively if the
current accessible is not a widget as well.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/7058
Fixes 6074a18e3e
Add a uses-gl property to our sink implementation, and use
it in the paintable code. This avoids juggling a second gl
context, with the risk of leaking it.
