Apparently, by comparing with the other backends, we should not call
_gdk_win32_append_event() after calling gdk_scroll_event_new() but we should
call it after calling gdk_scroll_event_new_discrete(), which was why we didn't
restore the cursor after we scroll using the mouse wheel and didn't manage to
remove the shade that appears after we scrolled to the very top or very bottom.
Also, as suggested by the reporter, use IDC_SIZEALL for the system cursor that
we fall back to if no cursor theme is installed, as with other Windows
programs.
This should really fix issue #3581.
In GTK4, we are now defaulting to the OpenGL renderer with the Cairo renderer
only used as a fallback, so there is no point keeping the code paths that use
layered windows as layered windows do not work well with OpenGL nor Vulkan.
Have an implementation of ->request_layout() and ->compute_size() for the Win32
surface backend so that we can properly display and move and resize the
windows, as we request from the Win32 APIs.
Hxndling Aerosnap properly is mostly done except for snap_up(), which needs to
to be looked at later.
It was used by all surfaces to track 'is-mapped', but still part of the
GdkToplevelState, and is now replaced with a separate boolean in the
GdkSurface structure.
It also caused issues when a widget was unmapped, and due to that
unmapped a popover which hid its corresponding surface. When this
surface was hidden, it emitted a state change event, which would then go
back into GTK and queue a resize on popover widget, which would travel
back down to the widget that was originally unmapped, causing confusino
when doing future allocations.
To summarize, one should not hide widgets during allocation, and to
avoid this, make this new is-mapped boolean asynchronous when hiding a
surface, meaning the notification event for the changed mapped state
will be emitted in an idle callback. This avoids the above described
reentry issue.
This removes the GDK_CONFIGURE event and all related functions and data
types; it includes untested changes to the MacOSX, Win32 and Broadway
backends.
Reading the comment, it seems to be related being a window manager
decoration utility; this is not something GTK4 aims to handle, just drop
support for this.
The keycode and modifier (state) parameters are in the wrong order
for gdk_key_event_new() in the gdk win32 backend, which causes
key up/down events to be populated incorrectly.
Call SetCapture() explcitly for the (new) modal window so that we make the
modal window respond to mouse input, and also call SetCapture() to the parent
of the transient window that we are destroying so that mouse input capture is
returned to the parent window.
This attempts to fix the following:
* Upon creating a new modal window, the new modal window does not receive
pointer input unless one switches to another program and back
* Upon closing a transient window, the parent window that activated the
transient window does not receive pointer input unless one switches to
another and back
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direct3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license.
-Build libepoxy on Windows with EGL support enabled.
-Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs
to be set with gl-gles as at least one of the flags.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There are no plans to do this in this
commit.
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
Use better matching format modifiers/specifiers, initialise some things
which in theory wont be written to because of getters using g_return_if_fail(),
a cast, and gsize as input for malloc because gsize!=glong on 64bit Windows.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
Add all of the keyboard translation results in the key event,
so we can translate the keyboard state at the time the event
is created, and avoid doing state translation at match time.
We actually need to carry two sets of translation results,
since we ignore CapsLock when matching accelerators, in
gdk_event_matches().
At the same time, drop the scancode field - it is only ever
set on win32, and is basically unused in GTK.
Update all callers.
The win32 backend is using GDK_MOD2_MASK for AltGr,
so define GDK_MOD2_MASK locally to keep this working,
but remove any mention of GDK_MOD3_MASK,...,GDK_MOD5_MASK.
These fixes were done blindly, to make the ci pass,
and will need review by somebody with access to an
actual win32 system to make sure the surface subtypes
are implemented properly.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
The "iconified" state is mostly an X11-ism; every other platform calls
this state "minimized" because it may not involve turning a window into
an icon at all.
Windows/surface's aren't supposed to be explicitly moved by any external
part, so don't provide API for doing so. Usage throughout Gdk is
replaced by the corresponding backend variants.
1) In the SetWindowPos() function (and the WINDOWPOS struct) the
"hWndInsertAfter" argument/field means the window that will be
directly above after the change, not the window that will be
directly below. MSDN says "precedes" for SetWindowPos(), but
WINDOWPOS documentation is more precise: this is the window
behind which the affected window will be placed. Apparently,
Z-axis goes back-to-front.
Therefore, logging should be reworded correctly.
2) When we switch away from the application and then switch back
to a transient window, we need to bring up its transient-owner
(and its transient-owner's owner and so forth) as well,
otherwise our transient (modal) window might be transient for
something that might not be visible.
3) When we bring up a window, we should bring all of its children
(popup windows) on top of it.
Because Windows doesn't provide a function to bring one window
on top of the other, we have to work around this by calling
SetWindowPos() twice, swapping the windows between the calls.
Popups can't be active or inactive, so emitting GDK events
in response to WM_ACTIVATE makes no sense for these kinds
of GDK surfaces.
The jury is still out on whether we should block (return 0)
or ignore (don't return anything) this message.
Blocking WM_NCACTIVATE (which we currently ignore) is definitely
not an option - it completely breaks input somehow.
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
See !426 for the gtk3 MR
This leverages the normal input context switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input context
switching code, which, not being able to create the desired context
(which is and empty string), falls back to looking at current
keyboard layout (currently that code is still a FIXME).
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of switching to
the appropriate IM context at runtime. At least, the kinds of context
that specify languages for which they are used automatically by default
(once locale matching is implemented), and the IME context.
Loading other kinds of IM context might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of using the IME context that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit d64467b334 changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
In particular, this patch removes:
gdk_surface_get_events()
gdk_surface_set_events()
gdk_surface_get_device_events()
gdk_surface_set_device_events()
Event masks so far still exist for grabs.
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
It's quite old, but mostly harmless (both "message == WM_KEYUP"
and "message = WM_KEYUP" evaluate to not-FALSE, and message
value is not used after that line).
* Remove DC refcounting (we trust GDK to always do
begin_frame/end_frame calls in pairs)
* Now that there's no GDK-provided double-buffer up the stack,
double-buffering is implemented here
(though it's disabled by default - in my tests it didn't provide
any visual improvements, but did decrease performance).
* For some reason delaying window resizes until the point where
we need to blit the double-buffer into the window leads
to visual glitches, so doulbe-buffered windows are resized
in begin_frame, same as non-double-buffered ones.
* New code to clear the paint region, for all drawing modes.
Hopefully, it isn't duplicated anywhere up the stack.
* GL has its own context now, so remove any GL-related comments.
* Layered windows are still used (because cairo actually works
better with them)
* A bit more code re-use for layered windows
* Some functions that were local to gdksurface-win32.c are made
usable for the whole backend
* Drag-indicator drawing is temporarily commented out to match
a similar change in X11 backend
This commit ensures that each GdkSurface impl remembers the
cursor that GDK sets for it, and that this cursor is set
each time WM_SETCURSOR is called for that sufrace's HWND.
This is needed because W32, unlike X, has no per-window cursors -
the cursor on W32 is a global resource, and we need to keep track
of which cursor should be set when pointer is over which surface
ourselves (WM_SETCURSOR exists exactly for this reason).
This commit also makes GDK remember the surface that has an implicit
grab (since implicit grabs are gone from the upper levels of the toolkit),
and ensures that crossing events are correctly synthesized and the grab
is broken when surface focus changes. This fixes a bug where opening
a new window (by clicking something in some other, pre-existing window)
will make that new window not get any mouse input due to the fact
that the mouse-button-down event from that click caused an implicit
grab on the pre-existing window, and that grab was not released afterward.
Add a new W32 backend-specific message filtering mechanism.
Works roughly the same way old event filtering did, but without
events (events are GDK/X11 concept that never really made sense
on W32), so there's no functionality for 'altering' events being
emitted. If an event needs to be emitted in response to a message
do it yourself.
Implemented like this, it should give better performance than
if we were to use GLib signals for this, since W32 sends a LOT
of messages (unlike X11, which doesn't send events as often)
all the time, and invoking the signal machinery on *each* message
would probably be bad.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection
is mostly gone, and the word "selection" does not reflect the
functionality of this object too well.
Clipboard is now handled by a separate thread, most of the code for
it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses
clipdrop as a backend.
The DnD source part is also put into a thread.
The DnD target part does not spin the main loop, it just
emits a GDK event and returns a default value if it doesn't get a reply
by the time the event is processed.
Both clipboard and DnD use a new GOutputStream subclass to get data
from GTK and put it into a HGLOBAL.
GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext,
anticipating a similar change that slated to happen to GdkDragContext.
OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0
to make GDK use the old LOCAL and DROPFILES protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This is an automatic rename of various things related
to the window->surface rename.
Public symbols changed by this is:
GDK_MODE_WINDOW
gdk_device_get_window_at_position
gdk_device_get_window_at_position_double
gdk_device_get_last_event_window
gdk_display_get_monitor_at_window
gdk_drag_context_get_source_window
gdk_drag_context_get_dest_window
gdk_drag_context_get_drag_window
gdk_draw_context_get_window
gdk_drawing_context_get_window
gdk_gl_context_get_window
gdk_synthesize_window_state
gdk_surface_get_window_type
gdk_x11_display_set_window_scale
gsk_renderer_new_for_window
gsk_renderer_get_window
gtk_text_view_buffer_to_window_coords
gtk_tree_view_convert_widget_to_bin_window_coords
gtk_tree_view_convert_tree_to_bin_window_coords
The commands that generated this are:
git sed -f g "GDK window" "GDK surface"
git sed -f g window_impl surface_impl
(cd gdk; git sed -f g impl_window impl_surface)
git sed -f g WINDOW_IMPL SURFACE_IMPL
git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE
git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface
git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface
git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface
git sed -f g gsk_renderer_get_window gsk_renderer_get_surface
git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface
(cd gdk; git sed -f g window_type surface_type)
git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type
git sed -f g window_at_position surface_at_position
git sed -f g event_window event_surface
git sed -f g window_coord surface_coord
git sed -f g window_state surface_state
git sed -f g window_cursor surface_cursor
git sed -f g window_scale surface_scale
git sed -f g window_events surface_events
git sed -f g monitor_at_window monitor_at_surface
git sed -f g window_under_pointer surface_under_pointer
(cd gdk; git sed -f g for_window for_surface)
git sed -f g window_anchor surface_anchor
git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL
git sed -f g native_window native_surface
git sed -f g source_window source_surface
git sed -f g dest_window dest_surface
git sed -f g drag_window drag_surface
git sed -f g input_window input_surface
git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
This renames the GdkWindow class and related classes (impl, backend
subclasses) to surface. Additionally it renames related types:
GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType,
GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge
This is an automatic conversion using the below commands:
git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass
git sed -f g GdkWindow GdkSurface
git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing
git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING
git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2"
git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE
git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo
git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE"
git sed -f g "broadway_window" "broadway_surface"
git sed -f g "BroadwayWindow" "BroadwaySurface"
git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE"
git sed -f g "wayland_window" "wayland_surface"
git sed -f g "WaylandWindow" "WaylandSurface"
git sed -f g "X11_WINDOW" "X11_SURFACE"
git sed -f g "x11_window" "x11_surface"
git sed -f g "X11Window" "X11Surface"
git sed -f g "WIN32_WINDOW" "WIN32_SURFACE"
git sed -f g "win32_window" "win32_surface"
git sed -f g "Win32Window" "Win32Surface"
git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE"
git sed -f g "quartz_window" "quartz_surface"
git sed -f g "QuartzWindow" "QuartzSurface"
git checkout NEWS* po-properties
The GDK_POINTER_MOTION_HINT_MASK enumeration value is gone, but we're
still keeping around the "is_hint" field in GdkEventMotion, even though
every backend sets it to `false` — except for the core X11 device
manager.
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
We need to know the target atom value to know when we need to
do something with side-effects (since side-effects are expressed via
special target values). Previously, the code side-stepped that by looking
at the data type (which was rather unique for the one side-effect
target that we supported, signalled by the TARGETS target),
but for the DELETE target that seems to be no longer an option, hence the new
field to carry this information past the convert_selection() routine.
This prevents GDK from throwing a warning when trying to convert
a DELETE target, which has no format or data objects set.
The side-effects for the DELETE target happen earlier, in GTK layer.
By the point it gets to change_property(), it's a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Handle WM_CANCELMODE and do nothing in response to it when DnD is
active. Otherwise pass it to DefWindowProc, which will call ReleaseCapture()
on our behalf.
This prevents us from losing mouse capture when alt-tabbing during DnD
(this includes the feature of Windows Explorer where dragging stuff over
a window button in the taskbar causes that window to receive focus, i.e.
keyboardless alt-tabbing).
https://bugzilla.gnome.org/show_bug.cgi?id=786509
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
Instead of using a boolean to indicate a modal operation being in progress,
use a set of flags, and allow these to be set and unset independently.
Specifically, this allows WM_CAPTURECHANGED handler to only act when a drag-move or
drag-resize modal operation is in progress, and ignore DND (which can also cause
WM_CAPTURECHANGED to be posted). This avoids a crash due to assertion failure when
OLE2 DND code tries to end a modal operation that was already ended by the WM_CAPTURECHANGED
handler.
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786121
Commit 1d0fad3 revealed that there were some assumptions made that were
actually to compensate for the bug fixed by that commit, so we need to
remove those assumptions as they would result in AerSnap to not work
properly on HiDPI screens.
Also re-do how we set the x and y positions of our GdkWindow, so that we
are more consistent across the board when we go between a GDK window
coordinate and a Windows API window cooredinate.
This would also simplify the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=785999
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
Windows WM handles AeroSnap for normal windows on keydown. We did this
on keyup only because we do not get a keydown message, even if Windows WM
does nothing with a combination. However, in some specific cases it DOES
do something - and we have no way to detect that. Specifically, winkey+downarrow
causes maximized window to be restored by WM, and GDK fails to detect that. Then
GDK gets a keyup message, figures that winkey+downarrow was pressed and released,
and handles the combination - by minimizing the window.
To overcome this, install a low-level keyboard hook (high-level ones have
the same problem as normal message loop - they don't get messages when
Windows WM handles combinations) and use it to detect interesting key combinations
before Windows WM has a chance to block them from being processed.
Once an interesting combination is detected, post a message to the window, which
will be handled in due order.
It should be noted that this code handles key repetitions in a very crude manner.
The downside is that AeroSnap will not work if hook installation function call fails.
Also, this is a global hook, and if the hook procedure does something wrong, bad things
can happen.
https://bugzilla.gnome.org/show_bug.cgi?id=776031
Instead of checking for window state and giving it extra styles that
fit, just give it all styles that it is missing. It turned out that
otherwise it is impossible to, for example, restore a maximized window
via sysmenu. Also, be more flexible towards GDK/WM window state mismatches
and consider the window minimized/maximized if *either* GDK or WM thinks so.
https://bugzilla.gnome.org/show_bug.cgi?id=776485
When primary monitor is smaller than the actual monitor on which the
window is being maximized, the WM will do widnow size adjustments
that will completely screw the window size if we try to make it
smaller than 100% fullscreen (to account for taskbar size, for example).
Fix this by overriding maximized window size during WM_WINDOWPOSCHANGING.
https://bugzilla.gnome.org/show_bug.cgi?id=775808
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
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
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
