Passing a rectangle with zero width or height to xdg_shell-v6
set_anchor_rect() will cause a protocol error and terminate the client,
as with gedit when pressing the Win key.
Reason for this is because the rectangle used to set the anchor comes
from gtk_text_layout_get_iter_location() which uses the pango layout
width/height, which can be empty if there is not character at the given
location.
Make sure we don't use 0 as width or height as an anchor rectangle to
avoid the protocol error, and compensate the logical position of the
given rectangle if the size is changed, so that the actual position
remains as expected by the client.
https://bugzilla.gnome.org/show_bug.cgi?id=777176
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 using some kind of flawed logic about modifying a keypress result
when CapsLock is toggled, just add a CapsLock shift level (and all derived
shift levels, i.e. Shift+CapsLock and CapsLock+AltGr and Shift+CapsLock+AltGr)
and query Windows keyboard layout API about the result of keypresses involving
CapsLock.
Keysym table is going to be (roughly) twice as large now, but CapsLock'ed
keypresses will give correct results for some keyboard layouts (such as
Czech keyboard layout, which without this change produces lowercase letters
for CapsLock->[0,2,3,4...] instead of uppercase ones).
Keymap update time also increases accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=165385
We have a frame clock that ensures rendering is done as per the
output vsync. There is no need to have Mesa do the same for us.
This, most notably, ensures Mesa doesn't schedule frame callbacks
that will be left unattended if the compositor stops throttling
frames for its surface, this is eg. the case if the toplevel is
moved to another workspace.
Also, given a SwapInterval!=0 will always bring these unexpected
side effects, check that it's possible to disable it, and spew
a debug message if that isn't the case.
https://bugzilla.gnome.org/show_bug.cgi?id=769835
If there are no targets, DnD is probably intended to be local,
add a mimetype for matching then. The wayland protocol requires
at least one wl_data_offer.target call with the mimetype selected
for transfer.
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
Just set check_for_dpi_awareness = TRUE and eventually it will be handled
correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions
are NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777031
When a subsurface is used as a parent of a popup, GDK needs to traverse
up to the transient-for as the next parent, to properly find the parent
used by the popup positioner. This is because the parent of a popup
must always either be an xdg_popup or an xdg_surface, but traversing
the "parent" (in GDK terms) upwards from a subsurface will end up on
the fake root window before we hit the actual parent (in Wayland terms).
https://bugzilla.gnome.org/show_bug.cgi?id=776225
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
For subsurfaces, the new state which includes the input shape is not
applied by the compositor if the subsurface is in effective synchronous
mode.
So we need to apply the input shape once parent surface is in effective
desynchronized mode, which is when it's committed, otherwise the input
shape may never be applied if the widget is not using being_paint() /
end_paint() to draw on its subsurface, like clutter does.
We do that only for empty input shape as those won't need update when
the subsurface is resized, for all other non-empty input shape, the
client still has to use begin_paint()/end_paint() for the input shape to
be applied.
https://bugzilla.gnome.org/show_bug.cgi?id=774534
We check when we realize the GdkGLContext, but we never use the check
before using the API, and it breaks on drivers that do not implement the
extension, or on drivers that only support OpenGL ES 2.0.
Wayland subsurfaces can have other native window parents, but those need
to be destroyed along with the rest of the window hierarchy otherwise
an assert() is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=774915
gdk_window_get_toplevel() walks up the windows tree looking for the
corresponding toplevel window, but needs to account for subsurfaces as
well on Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=775319
The recent Wintab testing revealed an interesting edge case: we cannot
for certain say that windowing system messages will not be received
while the default display and its device manager are still being set up.
We've ruled out the Wintab case now, but cannot rule out some future bit
of runtime DLL code doing stuff at this critical time.
This commit detects and avoids a potential null pointer dereference in
the message handling code while detecting grabs. Grabs don't really
exist yet, if the default display and/or its device manager are not yet
globally known.
https://bugzilla.gnome.org/show_bug.cgi?id=774379
Now that subsurfaces can be created as child of another GdkWindow (and
not just the root window), they must be placed according to the location
of their parent, i.e. the abs_x/abs_y must be updated and taken into
account when placing and moving subsurfaces under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=774917
Only attempt to initialize Wintab after the display manager announces
that the first default display has been set. Fixes a segfault during
initialization of specific tablet drivers' wintab32.dlls. Add assertions
and verbose comments explaining this nonsense because this stuff is a
pain to have to keep fixing.
https://bugzilla.gnome.org/show_bug.cgi?id=774379
Move the orientation sanity-checks into the packet decode func.
Rationale: the packet handling func may otherwise read beyond the end of
device->last_axis_data.
Also expand them to cope with my test Huion's weird reporting.
Also correct the azimuth angle to align with GDK's presentation.
Most importantly, fix annoying comment typo.
https://bugzilla.gnome.org/show_bug.cgi?id=774265
Fix a regression introduced in 4ce6d10601
which causes devices with an odd-numbered zero-based index in the list
to be passed over incorrectly. This might present as yet another "device
does not send pressure" bug for ~50% of devices out there.
This commit also closes off another potential segfault for wintab_devices
lists which have an odd length.
https://bugzilla.gnome.org/show_bug.cgi?id=774699
Under Wayland, a subsurface can have another surface as parent, but
gdk would not allow native windows if the parent is not the root window.
Allow native subsurface for all parent under Wayland, not just for the
root window.
https://bugzilla.gnome.org/show_bug.cgi?id=774475
This can be triggered on workspace switches, and on hidpi results in
the scale factor being reset to 1 while the window is not in the
current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=774476
As in the last commit on gdkdisplay-win32.c, we need to define that to be
0x0600 (Vista) or later so that the items needed in the Windows headers be
activated.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
... to be for Vista (0x0600) or later. This is so that the necessary
items in the Windows headers be activated so that the code will build
properly on mingw-w64, and we already require Vista or later for GTK+.
Thanks Ting-Wei Lan for pointing this out.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
The monitors are already in scaled pixels, so scaling again when retrieving
the screen size is wrong.
With GDK_SCALE unset, the initial monitor sizes are unscaled, and when the
xsettings client sets a scale > 1, the monitor sizes should be updated.
The end result is that the monitor sizes start out wrong, and get
corrected on the first xrandr event, while the screen size starts out
right and becomes wrong after the event.
This patch fixes Firefox misplacing menus and popovers when the xrandr
configuration changes while it is running.
Fix for the X11 side of
https://bugzilla.gnome.org/show_bug.cgi?id=772202
For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
This way we can recommend that applications use the
fullscreen_on_monitor() API on both X and Wayland otherwise they'd
have to keep a path for each backend to achieve this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=773857
gdk_wayland_window_attach_image() is normally called from
gdk_window_end_paint() to notify the compositor of newly staged drawing.
If any of the drawing code inadvertently dispatches the wayland event
loop (for instance with a gdk_flush() call), then it's possible that by
the time gdk_window_end_paint() is called, the staged drawing is already
destroyed.
This commit bypasses the attach_image call in scenarios where the staged
drawing is prematurely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=773274
Update the GDKGL implementation:
-Allow legacy contexts to be created.
-Use finer-grained attributes to ask for a pixel format when possible,
which also adds support for anti-aliasing
In fact the changes here are required for GTKGL to work properly on
Windows for 4.x.
Note that creation of gles contexts are not done here, as the system does
not support such contexts directly on Windows, but only through means such
as ANGLE, which is a totally different issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=773528
GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a
legacy profile from the underlying windowing system, the OpenGL version
will be fixed to 3.0. If that happens, we need to set the legacy bit on
the GdkGLContext, since that bit will be used to determine the version
and type of GLSL shaders that will be used by application and toolkit
code alike.
(cherry picked from commit 31c05771e9)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
