Using UpdateLayeredWindow() on iconic windows brings them *back* from
their iconic (minimized) state. That is bad.
As a precaution, also don't use SetWindowPos() on iconic windows.
This means that iconic windows can't be moved. That is fixable
by using SetWindowPlacement(), but there is no pressing need to do so,
as there are very few cases when windows need to be moved while minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=763835
Two errors here:
1) A typo in splashscreen rectangle calculation - sets right twice
instead of setting top
2) Centering for dialogs is off because it doesn't convert
GDK virtual desktop coordinates to Windows WM virtual desktop
coordinates by adding _gdk_offset_*
https://bugzilla.gnome.org/show_bug.cgi?id=763628
This code:
> gdk_window_get_root_origin (window, &x, &y);
> x -= root_x;
> y -= root_y;
> pointer_window = gdk_device_get_window_at_position (device, &x, &y);
was meant to find the child gdk window at coordinates root_x and root_y.
These 4 lines had 2 bugs:
1) x = x - root_x (same for y) is wrong, it should be x = root_x - x
2) gdk_device_get_window_at_position() does not give you the window
at position x and y. It gives you the window under the device
(mouse pointer) and the returns the device coordinates in x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=763533
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
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
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* 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
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
Except for the init function, all the visual related code is made
of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
we avoid keeping other static variables and instead store the info
inside the screen struct.
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
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
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
