GTK knows when a surface is modally blocked and automatically drops
button press and release events, so do not block input in advance
from WM_MOUSEACTIVATE.
This function is probably not generally useful for a Gtk+/win32 user,
and it's only used internally by gdk-win32. It's time to deprecate it, I
believe.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Right now we only support system DPI awareness in GTK4. In that case
it makes sense to scale text with the DPI of the primary monitor, like
done in GTK3.
We plan to land support for proper fractional scaling in Gdk/Win32, so
in the future the "gtk-xft-dpi" setting will be gathered as intended,
i.e. for text magnification, as an a11y feature.
The function isn't used by Gtk itself anymore, and does not help much.
It creates extra issues for bindings, as it doesn't fit well with code
doing the same job for other objects.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The function is gone since commit ea65abc7e2 ("Rewrite
GdkWin32Keymap (load table directly from layout DLL)")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
DnD under Windows needed 3 fixes to work with Gtk.DropTarget.
1. The droptarget_w32format_contentformat_map list never gets
filled so the gdk_win32_drop_read_async throws
"No compatible transfer format found".
This is an easy fix and done the same way in the win32 clipboard code.
2. After a drop no gdk_drop_emit_leave_event gets emitted.
This causes a second drop to trigger a bunch of assertion
'self->drop == drop' failed because the first drop is still active.
This is also an easy fix and done the same way by the macos backend.
3. Handling gdk_drop_status/gdk_drop_get_actions interaction.
In gtk_drop_target_do_drop the code
```gdk_drop_finish (self->drop, gdk_drop_get_actions (self->drop));```
calls the finish operation with the actions of the drop which triggers
```g_return_if_fail (gdk_drag_action_is_unique (action));```
in gdk_drop_finish. The code assumes that GdkDrop::actions gets
narrowed down by calling gdk_drop_status. This is hard to assure
because at the same time gdk_drop_get_actions is used by
gtk_drop_target_accept to figure out if a drag is accepted.
GdkDrop::actions serves a double purpose here as the supported source
actions and the currently agreed on action. Both the x11 and the
wayland backend get this wrong somewhat too. Under wayland/x11 when
a drag coming from a source that supports both MOVE and COPY is
first hovering a drop target that only supports COPY it is afterwards
no longer accepted by other drop targets only accepting MOVE.
Under x11 this is permanent for this drag but with wayland the drag
recovers when hovering other widgets. The win32 backend now sets the
supported source actions before any enter/move/drop and narrows them
down in gdk_win32_drop_status.
The patch only touches the win32 backend and fixes all three issues,
for me restoring DnD under windows.
Closes#4498
By setting and then getting the required version in a context, the code
was not respecting user requirements. Instead, simply get the requested
version by the user clipped by the requirements (display version)
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
The call to gdk_win32_clipboard_request_contentformats() can return NULL even
without an error condition being hit (such as when the system clipboard is
empty), so check whether the returned GdkContentFormat pointer is not NULL
before calling gdk_clipboard_claim_remote(), which expects it to be not NULL,
otherwise we face a warning from that funtion and the subsequent
g_object_unref().
This at least partially fixes issue #4796.
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
Instead of performing keyboard layout substitution whenever we find a matching
entry in the registry, first try to load the original layout and only attempt
substitution when that fails.
See #4724
Some Windows keymaps have bogus mappings for the Ctrl modifier. !4423 attempted
to fix this by ignoring the Ctrl layer, but that was not enough. We also need to
ignore combinations of Ctrl with other modifiers, i.e. Ctrl + Shift. For example,
Ctrl + Shift + 6 is mapped to the character 0x1E on a US keyboard (but it should
be treated as Ctrl + ^). Basically, always ignore Ctrl unless it is used in
conjunction with Alt, i.e. as part of AltGr.
Related issue: #4667
