Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
Massive changes to OLE2 DnD protocol, which was completely broken before:
* Keep GdkDragContext and OLE2 objects separate (don't ref/unref them
together, don't necessarily create them together).
* Keep IDataObject formats in the object itself, not in a global variable.
* Fix getdata() to look up the request target in its format list, not in the
global hash table
* Create target GdkDragContext on each drag_enter, destroy it on drag_leave,
whereas IDropTarget is created when a window becomes a drag destination
and is re-used indefinitely.
* Query the source IDataObject for its supported types, cache them in the
target (!) context. This is how GTK+ works, honestly.
* Remember current_src_object when we initiate a drag, to be able
to detect later on that the data object is ours and use a
shortcut when querying targets
* Make sure GDK_DRAG_MOTION is only sent when something changes
* Support GTK drag cursors
* Ensure that exotic GTK clipboard formats are registered
(but try to avoid registering formats that can't be used between applications).
* Don't enumerate internal formats
* Ensure that DnD indicator window can't accept drags or receive any kind of input
(use WS_EX_TRANSPARENT).
* Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop()
* Fix indentation in gdk_win32_drag_context_drop_finish()
* Remove obsolete comments in _gdk_win32_window_register_dnd()
* Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab
break event in such cases (this allows alt-tabbing while DnD is in progress,
though there may be lingering issues with focus after dropping...)
* Support Shell ID List -> text/uri-list conversion, now it's possible
to drop files (dragged from Explorer) on GTK+ applications
* Explicitly use RegisterClipboardFormatA() when we know that the string
is not in unicode. Otherwise explicitly use RegisterClipboardFormatW()
with a UTF8->UTF16 converted string
* Fix _gdk_win32_display_get_selection_owner() to correctly bail
when selection owner HWND is NULL (looking up GdkWindow for NULL
HWND always succeeds and returns the root window - not the intended
effect)
* More logging
* Send DROP_FINISHED event after DnD loop ends
* Send STATUS event on feedback
* Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(),
so that it's closer to the point where last_pt and start_pt are set
* Use & 0x80 to check for the key being pressed. Windows will set low-order bit
to 1 for all mouse buttons to indicate that they are toggled, so simply
checking for the value not being 0 is not enough anymore.
This is probably a new thing in modern W32 that didn't exist before
(OLE2 DnD code is old).
* Fixed (hopefully) and simplified HiDPI parts of the code.
Also adds managed DnD implementation for W32 GDK backend (for both
OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but
there are some minor differences:
* doesn't use drag_window field in GdkDragContext,
uses the one in GdkWin32DragContext exclusively
* subtracts hotspot offset from the window coordinates when showing
the dragback animation
* tries to consistently support scaling and caches the scale
in the context
* Some keynav code is removed (places where grabbing/ungrabbing should
happen is marked with TODOs), and the rest is probably inert.
Also significantly changes the way selection (and clipboard) is handled
(as MSDN rightly notes, the handling for DnD and Clipboard
formats is virtually the same, so it makes sense to handle
both with the same code):
* Don't spam GDK_OWNER_CHANGE, send them only when owner
actually changes
* Open clipboard when our process becomes the clipboard owner
(we are doing it anyway, to empty the clipboard and *become* the owner),
and then don't close it until a scheduled selection request event
(with TARGETS target) is received. Process that event by announcing
all of our supported formats (by that time add_targets() should have
been called up the stack, thus the formats are known; just in case,
add_targets() will also schedule a selection request, if one isn't
scheduled already, so that late-coming formats can still be announced).
* Allow clipboard opening for selection_convert() to be delayed if it
fails initially.
* The last two points above should fix all the bugs about GTK+ rising
too much ruckus over OpenClipboard() failures, as owner change
*is allowed* to fail (though not all callers currently handle
that case), and selection_convert() is asynchronous to begin with.
Still, this is somewhat risky, as there's a possibility that the
code will work in unexpected ways and the clipboard will remain open.
There's now logging to track the clipboard being opened and closed,
and a number of failsafes that try to ensure that it isn't kept open
for no reason.
* Added copious notes on the way clipboard works on X11, Windows and GDK-W32,
also removed old comments in DnD implementation, replaced some of them
with the new ones
* A lot of crufty module-global variables are stuffed into a singleton
object, GdkWin32Selection. It's technically possible to make it a
sub-object of the Display object (the way Wayland backend does),
but since Display object on W32 is a singleton anyway... why bother?
* Fixed the send_change_events() a bit (was slightly broken in one of the
previous iterations)
* Ensure that there's no confusion between selection conversion (an artifact
term from X11) and selection transmutation (changing the data to be W32-compatible)
* Put all the transmutation code and format-target-matching code into gdkselection-win32.c,
now this code isn't spread across multiple files.
* Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c
* Extensive format transmutation checks for OLE2 DnD and clipboard.
We now keep track of which format mappings are for transmutations,
and which aren't (for example, when formats are passed as-is, or when
a registered name is just an alias)
* Put transmutation code into separate functions
* Ensure that drop target keeps a format->target map for supported formats,
this is useful when selection_convert() is called, as it only receives a
single target and no hints on the format from which the data should
be transmuted into this target.
* Add clear_targets() on W32, to de called by GTK
* Use g_set_object() instead of g_ref_object() where it is allowed.
* Fix indentation (and convert tabs to spaces), remove unused variables
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Some drivers don't do that (not sure whether that is the correct behaviour
or not). Remember each WT_PROXIMITY with LOWORD(lParam) != 0 that we get,
then look for a WT_CSRCHANGE. If WT_CSRCHANGE doesn't come, but a WT_PACKET
does, assume that this device is the one that sent WT_PROXIMITY.
Also include fallback code to ensure that WT_PACKETs for an enabled device
disable the system pointer, because WT_PROXIMITY handler might have
enabled it by mistake, since it's not possible to know which device left
the proximity (it might have been a disabled device).
https://bugzilla.gnome.org/show_bug.cgi?id=778328
Previously HiDPI scale was retrieved and applied too late in the initialization
process to affect monitor size and monitor workarea size, but the code that
initializes these sizes *did* try to use the scale, even though it was always
getting scale=1.
To fix this, move the too-late code into monitor enumeration routine.
This also fixes a probable semantic bug where width and height were divided
by scale, again.
Now monitor and workarea should be in application pixels (i.e. divided by scale),
as intended.
https://bugzilla.gnome.org/show_bug.cgi?id=778835
Just set check_for_dpi_awareness = TRUE and eventually it will be handled
correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions
are NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777031
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.
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.
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
This adds support to the GDK Win32 backend so that we can support Vulkan
context creation for use in the GSK Vulkan renderer, so that we can test
it on Windows platforms as well.
https://bugzilla.gnome.org/show_bug.cgi?id=776544
... to be for Vista (0x0600) or later. This is so that the necessary
items in the Windows headers be activated so that the code will build
properly on mingw-w64, and we already require Vista or later for GTK+.
Thanks Ting-Wei Lan for pointing this out.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
Commit d249e77 (API: screen: Remove gdk_screen_is_composited()) attempted
to update the GDK-Win32 for the removal of the API, but some parts were
missed. This updates the code so that things continue to build and run.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
Delay as long as possible before calling OpenClipboard(),
call CloseClipboard() as quickly as possible after that.
Don't call OpenClipboard() when we don't need to (for example,
we don't need to open clipboard to call GetClipboardOwner()).
Also, print out actual W32 error code in some cases where it
was not printed before.
https://bugzilla.gnome.org/show_bug.cgi?id=763907
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
