Rendering doesn't do much about clipping drawing operations to the window shape,
although invalidation applies the shape to every window, leaving possibly trails
of "overrendered" content. So ensure the shape portions get invalidated too when
the window is moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=729095
It may happen that the received clipboard data is empty, but
if it's of type image/bmp, gtk+ will crash:
gdk_property_change: 00030AD4 GDK_SELECTION image/bmp REPLACE 8*0 bits:
... delayed rendering
gdk_selection_send_notify_for_display: 00030AD4 CLIPBOARD image/bmp
GDK_SELECTION (no-op)
_gdk_win32_selection_convert_to_dib: 1252003C image/bmp
Program received signal SIGSEGV, Segmentation fault.
0x749a9f40 in msvcrt!memmove () from C:\Windows\syswow64\msvcrt.dll
Thread 1 (Thread 2248.0x1b34):
target=0xc07b) at gdkselection-win32.c:1292
at gdkevents-win32.c:3498
wparam=8, lparam=0) at gdkevents-win32.c:232
message=773, wparam=8, lparam=0)
at gdkevents-win32.c:263
C:\Windows\syswow64\user32.dll
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
wparam=0, lparam=-1687549457)
at gdkevents-win32.c:248
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
https://bugzilla.gnome.org/show_bug.cgi?id=728745
The events are routed through a new slave device with type
GDK_SOURCE_TOUCHSCREEN, minimal tracking of touches is done
to keep the state for each of those.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The master pointer/keyboard pair should never disappear or be
inconsistent. The seat capabilities are now reflected through
slave devices, those may come and go freely as the seat
capabilities change. This also enables adding further capabilities
to handle eg. touch.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.
Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.
https://bugzilla.gnome.org/show_bug.cgi?id=726592
...on Windows 8+ and when the system setting for non-Unicode programs do
not match the language version of Windows by falling back to using Pango.
This ensures that the correct font is used during these scenarios, so that
we minimize the risk of seeing garbled characters for texts that the system
code page does not support due to system peculiarties. There might be a
way to support gtk-font-name handling using the native Windows APIs
directly on Windows 8+, but that needs to be investigated.
https://bugzilla.gnome.org/show_bug.cgi?id=726298
The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Lots of code, including dragging code in GtkWindow, use these
fields. Setting them to 0 causes lots of strange and weird bugs.
Use the same "hack" from query_device_state of just using
win_x / win_y for now. We'll convert this to the proper fake root
coordinate system used by get_root_coords in the next commit.
And the counterpart to unmaximize when dragging a maximized window, if
touch devices aren't going to use EWMH moveresize, having this one at least
makes things feel a bit less awkward.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
Sadly, EWMH moveresize mechanism can't work with touch devices for two
reasons:
1) As a mutter implementation detail, the device is queried in order
to check whether the dragging button is still pressed. Touch devices
won't report the button 1 being pressed through pointer emulation.
2) Even bypassing that check, on X11 touch events are selected prior
to sequences being started, either through XISelectEvents or
XIGrabTouchBegin, no late registering through active grabs is allowed,
as WMs do on reaction to EWMH moveresize messages.
So for the time being, make touch devices fallback on emulated window
dragging, which at least allows for moving windows.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.
https://bugzilla.gnome.org/show_bug.cgi?id=726187
