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
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
This prevents normal application windows (and other kinds of windows)
from being moved up in Z-order to be above windows that have the
always-on-top bit set. Doing so would make the previously-normal windows
in question also always-on-top implicitly.
Windows that are already always-on-top will be restacked on top of other
always-on-top windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=746745
Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle
it on an ad-hoc hidden window we create when opening the display.
This has two reasons:
1) we want emit the display::size-changed signal even if there are no
gtk windows currently open
2) we want to emit the signal just once and not once for every window
https://bugzilla.gnome.org/show_bug.cgi?id=757324
Windows does not send any release key event for one of the shift keys
when both shift keys were pressed together. This commit solves
the problem by sending the extra release key event for the shift key
which was released as first, when the other shift key is released.
Other modifiers (e.g. Ctrl, Alt) do not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=751721
In particular this means that cursors are disposed of by the way of
g_object_unref(), not DestroyCursor (which is documented to not to be
used on certain kinds of cursors, and we can't tell which is which).
It should also alleviate any concerns about destroying cursors that
are still in use by other windows, except for cases where we would
somehow get our hands on a HCURSOR that someone else is using and we
make a GdkCursor out of it and later unref and finalize it while it
is still in use.
It also removes the need to call CopyCursor(), which makes animated
cursors into non-animated ones as a side-effect (supposed to be a bug,
but try explaining that to MS). Now cursors should be animated (if
the are set up as such in the OS).
https://bugzilla.gnome.org/show_bug.cgi?id=697477
Requires Vista and newer.
* Create surfaces with cairo_win32_surface_create_with_format
* Provide an rgba visual that can be distinguished from the system visual
* Make rgba visual the best available visual
* Enable alpha-transparency for all windows that we control
* Check for appropriate cairo capabilities at configure time
(W32 - 1.14.3 newer than 2015-04-14; others - 1.14.0)
* Check for composition support before enabling CSDs
* Re-enable transparency on WM_DWMCOMPOSITIONCHANGED
Windows that were created while composition was enabled and that were CSDed
as a result and will look ugly (thick black borders or no borders at all) once
composition is disabled.
If composition is enabled afterwards, they will return back to normal.
This happens, for example, when RDP session is opened to a desktop where a GTK
application is running. For W7/Vista windows will only re-gain transparency after
the RDP session is closed. For W8 transparency will only be gone momentarily.
Windows that were created while composition was disabled will not be CSDed
automatically and will use SSD (WM decorations), while windows that are CSDed
manually will get a thin square border.
If composition is enabled afterwards, these windows will not change.
This is most noticeable for system menus (popup menus are often generated
on the fly, system menus are created once) and some dialogues (About dialogue,
for example).
https://bugzilla.gnome.org/show_bug.cgi?id=727316
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
Use (cairo) input shape of the window to check whether a point is inside or not
inside the window.
If it is, let the default window procedure do its thing (which seems to be
working all right in all known cases).
If it isn't, override the default window procedure and tell WM what we think.
Don't do any of the above if the window has CSD-incompatible styles (WS_BORDER
or WS_THICKFRAME).
This is a crude kind of substitute for window input shape support (which W32
does not seem to have). Still probably enough to be positive about input shapes
support.
https://bugzilla.gnome.org/show_bug.cgi?id=733679
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
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
The MINMAXINFO struct was being populated based upon geometry hints when
GDK_HINT_MAX_SIZE flag was enabled, then promptly having its values blown
away with default values.
https://bugzilla.gnome.org/show_bug.cgi?id=711110
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
(Broadway doesn't have a window system queue separate from the GDK event queue,
but we write the function the same way for consistency.)
https://bugzilla.gnome.org/show_bug.cgi?id=694274
We now have a proper MASTER/SLAVE input device split, where
the masters are virtual core input devices and we add fake hw
slave devices for the system pointer and real slave devices for
wintab devices.
We also set the proper source_device on the events so you can
tell which device sent it and properly decode the axis info.
