Ensure that things build again, and instead use the Windows API to
acquire the screen dimensions (note: this may need to be scaled for
HiDPI, but since I do not own a WinTab-based device, I will need to
keep the dimensions as-is for now).
Also update the gdkdnd-win32.c code to use formats rather than targets.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Instead, turn the functions into backend API:
gdk_broadway_display_add_selection_targets()
gdk_broadway_display_clear_selection_targets()
Remove the old per-backend functions, too.
Like the X11 and Wayland backends, re-work how the cursors are being
handled. So, we use a hash table to cache up the HCURSORS that we
create along the way.
We still need to cache up the icon/cursor themes since this is something
that is not part of Windows but was added on to support icon/cursor themes
such as Adwaita on Windows, but should be in-line with what is going on in
GdkCursor.
Also, remove the _gdk_grab_cursor global variable in gdkprivate-win32.h,
and replace it with another variable in the GdkWin32Display structure,
to make things cleaner in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Since on Windows we need to use a good amount of temporary GL contexts,
we need to switch back to the original GL contexts we were using when
we are done with the temporary GL contexts, otherwise multi-GL windows
will cause confusions causing display artifacts and crashes.
Also, use the GdkWin32GLContext::gl_hdc consistently throughout
the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out
that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the
GL context is bound to becomes incorrect in sceanarios using multiple
windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in
programs that use multiple windows with GtkGLArea/GdkGLArea items, and it
turns out that GdkWin32Display::gl_hdc is actually not necessary to help
keep track of the HDCs we use for our GL contexts.
This will also fix on Windows with GDK_GL=always, or when GSK's gl
renderer is used.
Partly based on patch from Lukas K <lu@0x83.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=789213
Move the leftovers from the removals to use the current APIs, to fix the
build. Also for gdk_device_virtual_set_window_cursor(), only do
something when a valid GdkCursor is passed in here.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The preferred api to create cursors is by name, and the
GdkCursorType enumeration can directly trace its ancestry
to the horrible X cursor font. So lets stop using it.
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
Implement GdkDisplay->get_setting() using the existing
_gdk_win32_screen_get_setting() and get rid of GdkScreen->get_setting()
as a result, to follow the changes in GDK.
Also, since we don't emit settings events in the Windows GDK backend,
but we acquire settings to print using GDK_SETTING, drop all references
related to GDK_SETTING since that is now removed. Update the debug
strings that are print out as a result
(gdk_screen_get_setting->gdk_display_get_setting).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The list of surfaces passed into the function may be NULL, so don't try
to initialize the surfaces if it is so, to avoid a crash.
Also, remove the cast to GdkPixbuf* for getting surfaces->data, as we
are already using a cairo_surface_t*.
https://bugzilla.gnome.org/show_bug?id=773299
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
