If the compositor sends a keymap that fails on "compilation",
xkb_keymap_new_from_string() returns NULL, which makes xkb_state_new()
crash when assuming there is a keymap.
In these cases, gdk must remain with a xkb_state to handle modifiers/keys
properly, so warn about the invalid keymap string, and keep the previous
keymap (currently initialized to "us")
https://bugzilla.gnome.org/show_bug.cgi?id=735389
To all effects each window has its own "root" coordinates system, so set
toplevels at 0,0 in that coordinate system, so root coordinate calculations
are locally right.
https://bugzilla.gnome.org/show_bug.cgi?id=729215
This implements native fullscreen mode on OS X >= 10.7. This patch
adds tracking of the fullscreen mode if externally modified, as well
as toggling the native fullscreen mode of the window as needed.
At the present time broadway listens only for TCP/IP incoming
display connections. This patch implements the support for listening
on unix domain sockets too, adding the broadway_server_on_unix_socket_new()
constructor and the commandline option --unixsocket [path] to broadwayd.
https://bugzilla.gnome.org/show_bug.cgi?id=734420
X11 backend doesn't, and for good reason - main code body does not check
that the window it sets opacity for is, in fact, toplevel.
Just silently fail to do anything for non-toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=733769
Support environment variable GDK_WIN32_FONT_RESOLUTION that can be set to
a desired dpi (72, 96, 130, etc) to override system settings. Useful for
debugging, since changing system font scaling requires the user to log off
and log on again.
https://bugzilla.gnome.org/show_bug.cgi?id=734038
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
Delay the keyboard settings creation until we're delivering the key
press. This means we don't have to create the settings for a server that
sends us repeat information.
This function currently calls gdk_win32_window_shape_combine_region(),
which is wrong, because it leads to SetWindowRgn() being called with
non-NULL region, which makes W32 disable theming (particularly - decoration
theming), which makes decorations revert back to old GDI-drawn Windows 2000
variant, which looks out of place and interacts *badly* with alpha channel
(because GDI).
https://bugzilla.gnome.org/show_bug.cgi?id=733671
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
Some windows, like GtkWindow and some other apps, set a transparent
background. The guarantee for begin_paint_region is that there should
be a full clear to the specified background color, not a composite
against what was there before.
This fixes repaint artifacts in Wayland and Weston in a better way than
76922c169f.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
