The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927
Signed-off-by: Simon McVittie <smcv@debian.org>
The filetransfer protocol says to use
application/vnd.portal.filetransfer, but I used
application/vnd.portal.files when I implemented the
protocol. Oops.
This commit dds the correct mimetype, but we still
support the old one to preserve interoperatibility
with existing flatpaks using GTK 4.6.
Fixes: #5182
We need to register the portal mime types before
the others to prefer them, doing this call async
messes up that ordering.
This is effectively reverting 69fb3648b2
`apply_monitor_change()` already calls `update_scale()`.
Note that this only affects old compositor versions (see
`should_update_monitor()`) so it's just a minor cleanup.
This function is probably not generally useful for a Gtk+/win32 user,
and it's only used internally by gdk-win32. It's time to deprecate it, I
believe.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Right now we only support system DPI awareness in GTK4. In that case
it makes sense to scale text with the DPI of the primary monitor, like
done in GTK3.
We plan to land support for proper fractional scaling in Gdk/Win32, so
in the future the "gtk-xft-dpi" setting will be gathered as intended,
i.e. for text magnification, as an a11y feature.
The function isn't used by Gtk itself anymore, and does not help much.
It creates extra issues for bindings, as it doesn't fit well with code
doing the same job for other objects.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Commit 59f6c50df8 set the memory limit to 100M,
which turns out to exclude some large, valid jpegs.
So, bump things to 300M, matching what was done
in gdk-pixbuf.
The function is gone since commit ea65abc7e2 ("Rewrite
GdkWin32Keymap (load table directly from layout DLL)")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Starting with the Wayland protocol wl_pointer >= 8, discrete axis
events have been deprecated in favour of high-resolution scroll event.
Add a listener for high-resolution scroll events and, for backwards
compatibility, handle discrete events as discrete*120.
Instead of calculating the discrete scroll deltas in
GtkEventControllerScroll, move that code to the event constructor and
access the precalculated values using gdk_scroll_event_get_deltas.
Refactor, no functional changes.
Starting with Linux Kernel v5.0 two new axes are available for
mice that support high-resolution wheel scrolling: REL_WHEEL_HI_RES and
REL_HWHEEL_HI_RES.
Both axes send data in fractions of 120 where each multiple of 120
amounts to one logical scroll event. Fractions of 120 indicate a wheel
movement less than one detent.
The 120 magic number is a copy of the Windows API, so this new
constructor can be used both in Linux >= 5.0 and Windows >= Vista.
Add missing #define g_memdup2() for gdksurface-broadway.c in case of enabled
broadway-backend as used otherwise.
Copy static would_drop() replacement for g_log_writer_default_would_drop()
from gtk-builder-tool.c to gtk-reftest.c
Even though the argument is non-nullable, GTK sometimes incurs in that
by itself by destroying the surface while the event is in flight. This
is the case of popping down a GtkDropdown. When this happens we simply
ignore the crossing event, but we should let it through instead, the
compositor did not send it in vain and we possibly still have pointer
state to undo.
Drop the surface checks, so that the event is propagated along GTK.
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
If we get an invalid TARGETS reply, we might not have a valid 'type',
which ends up as NULL and segs in the g_str_equal.
(This is probably fallout from my fix 506566b6a4, which I still
can't reproduce reliably, so the last one just moved the seg a bit
further along, and we still don't know who is sending a bad TARGETS).
This corresponds to:
https://bugzilla.redhat.com/show_bug.cgi?id=2062143
C API users can keep dealing with the implicit equivalence of
GdkFileList and GSList, but language bindings have no idea that one type
is another, and none of them exposes GSList as a type anyway, so they
will need a way to construct a GdkFileList.
Instead of making GdkFileList mutable, and re-implement GSList, we only
provide a constructors pair that lets you create a GdkFileList from a
linked list or from an array.
DnD under Windows needed 3 fixes to work with Gtk.DropTarget.
1. The droptarget_w32format_contentformat_map list never gets
filled so the gdk_win32_drop_read_async throws
"No compatible transfer format found".
This is an easy fix and done the same way in the win32 clipboard code.
2. After a drop no gdk_drop_emit_leave_event gets emitted.
This causes a second drop to trigger a bunch of assertion
'self->drop == drop' failed because the first drop is still active.
This is also an easy fix and done the same way by the macos backend.
3. Handling gdk_drop_status/gdk_drop_get_actions interaction.
In gtk_drop_target_do_drop the code
```gdk_drop_finish (self->drop, gdk_drop_get_actions (self->drop));```
calls the finish operation with the actions of the drop which triggers
```g_return_if_fail (gdk_drag_action_is_unique (action));```
in gdk_drop_finish. The code assumes that GdkDrop::actions gets
narrowed down by calling gdk_drop_status. This is hard to assure
because at the same time gdk_drop_get_actions is used by
gtk_drop_target_accept to figure out if a drag is accepted.
GdkDrop::actions serves a double purpose here as the supported source
actions and the currently agreed on action. Both the x11 and the
wayland backend get this wrong somewhat too. Under wayland/x11 when
a drag coming from a source that supports both MOVE and COPY is
first hovering a drop target that only supports COPY it is afterwards
no longer accepted by other drop targets only accepting MOVE.
Under x11 this is permanent for this drag but with wayland the drag
recovers when hovering other widgets. The win32 backend now sets the
supported source actions before any enter/move/drop and narrows them
down in gdk_win32_drop_status.
The patch only touches the win32 backend and fixes all three issues,
for me restoring DnD under windows.
Closes#4498
This serial should be that from a button press/touch down/etc, use
the last implicit grab here, which will presumably be from the same
device that triggered the event.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5048
The XDND suggested action is a relic from when the source would control
the action for a drop. With the new GtkDropTarget the target decides
the action (not the source). That means the all of the returned
results from the ::enter and ::motion handlers will be unexpectely
ignored. Prefer to use the preferred action over the x11 suggested action.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4259
gdk_x11_drop_update_actions() sets actions to
drop_x11->suggested_action when !drop_x11->xdnd_have_actions
and then sets it again to drop_x11->suggested_action if it is.
If xdnd_have_actions is true use xdnd_actions.
Don't return to the main loop, instead force a run of the paint idle.
The paint idle will know to skip all the phases that aren't requested.
This is critically important becuase gdksurface.c assumes the
FLUSH_EVENTS and RESUME_EVENTS phases are matched, and we cannot
guarantee that if we return to the main loop and let various reentrant
code change the frame clock state.
This would lead to bugs with events being paused and never unpaused
again or even crashes.
Fixes#4941
If we take the early return we don't unscale this at the bottom of the
function, causing wrong coordinates in HiDPI screens.
This bug also affects GTK3 (I noticed this running Firefox tests on X).
The GdkToplevelSize struct already has the concept of "bounds", which
means the largest size a window should reasonably have. It's practically
the equivalent of the monitor the window is intended to be mapped on,
with the "struts" (e.g. panels) cut out. It's used by GTK to use this
information to calculate a default window size that is "lagom" (swedish;
not too large, not too small).
Simplify the API to just return the requirements that the user
has asked for. The rest of the code was undocumented and previously
used as a buggy source for a default value from internal code.
Since the buggy code is now fixed, remove all unnecessary cruft.
There are two reasons for this:
* First, the refactored realize code now makes sure that no
context with unsupported version is ever created.
* Second, this code could bump into false possitives and negatives, since
the user is not requested, nor expected to set_required_version
in any specific order relative to set_allowed_apis. Therefore,
some version could be rejected or accepted based on a set of
allowed apis that the user has not yet correctly configured.
Mimic the behavior of the egl context creation by stablishing
some sane logic for the api and version used. Split the decision
of the type of context (api, legacy) and the creation of a context
of a certain version and all its properties.
By setting and then getting the required version in a context, the code
was not respecting user requirements. Instead, simply get the requested
version by the user clipped by the requirements (display version)
It is useful for backends to get user set preferences while
ensuring the correctness of the result, which will be always
greater or equal than the minimum version provided
Add "stylus" to the list of substrings in a device name that cause it to be recognized
as a GDK_SOURCE_PEN device (previously "wacom", "pen" and "eraser"). Some devices
just use "stylus" in their name, and are otherwise recognized as
GDK_SOURCE_TOUCHSCREEN instead.
Fixes#4394.
When loading cursors at scale, we expect the
cursor images to have a size of scale * size.
If we don't find such images, load them at their
unscaled size and scale them up ourselves.
Without this, cursors will appear in unexpected
sizes depending on scales and themes.
Related: #4746
On Wayland it is a protocol violation to upload buffers with
dimensions that are not an integer multiple of the buffer scale.
Until recently, Mutter did not enforce this. When it started
doing so, some users started seeing crashes in GTK apps because the
cursor theme ended up with e.g. a 15x16 pixel image at scale of 2.
Add a small sanity check for this case.
Not updating shadow size unconditionally would lead to shadow size not
being set on map, which would lead mutter to think that we are a Window
without extents and then become confused when we suddenly set some.
Make sure that doesn't happen by always having shadows set on map, just
like GTK3.
Fixes#4136
There were several mistakes here.
The width of subtextures was set to the width of
the main texture, the data size wasn't properly
calculated, and the preconditions were inverted.
Yay us!
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
Previously, there was an issue with glitching after showing/hiding a
popover that was not also destroyed. This was due to the popover having
an update_freeze_count of zero after hiding the surface.
That resulted in it's toplevel continuously dropping frames such as during
high-frame-rate scrolling in textviews. This problem is much more visible
on high-frame-rate displays such as 120hz/144hz.
With this commit, we freeze the frame clock of the popup until it is
mapped again.
Since GdkTimeCoord stores only axis values, prior to this change,
if a device didn't report GDK_AXIS_X or GDK_AXIS_Y, the history
attached to merged motion events wouldn't contain any positional
information.
Commit 6012276093 already addressed
this issue for devices without tools by storing the event position
in GdkTimeCoord using GDK_AXIS_X and GDK_AXIS_Y and augmenting the
GdkTimeCoord's axis bitmask accordingly.
This change generalizes that workaround to all devices. Note that
if a device DOES report values for GDK_AXIS_X and GDK_AXIS_Y, those
values won't be overwritten.
Closes#4809
When a window is minimized by user action, the `showAndMakeKey` method is not executed when idle. This prevents the window from being un-minimized immediately.
And allow programmatic minimization of a window by un-minimizing them in `_gdk_macos_toplevel_surface_present`
Closes#4811
When given an invalid atom, gdk_x11_get_xatom_name_for_display can
return NULL and trigger a seg in gdk_x11_clipboard_formats_from_atoms.
Check for NULL.
Why I'm seeing a bad atom there is probably a separate question.
https://bugzilla.redhat.com/show_bug.cgi?id=2037786
The call to gdk_win32_clipboard_request_contentformats() can return NULL even
without an error condition being hit (such as when the system clipboard is
empty), so check whether the returned GdkContentFormat pointer is not NULL
before calling gdk_clipboard_claim_remote(), which expects it to be not NULL,
otherwise we face a warning from that funtion and the subsequent
g_object_unref().
This at least partially fixes issue #4796.
WebKit's GTK 4 port can give us textures with an internal format of
GL_RGBA with GL_UNSIGNED_NORMALIZED and a bit-depth of 8. This fixes
warnings for every GdkGLTexture created/delivered to the GskGLRenderer.
The format is essentially the same as GL_RGBA8 since it is normalized
between 0.0..1.0 for 8-bit components.
Fixes#4783
When surface depth switches from non-high-depth to high-depth (or vice
versa) the current surface has to be destroyed before a new one can be
created for this window. eglDestroySurface however was getting passed a
GdkDisplay, rather than the EGLDisplay it expects. As a result the old
surface did not get destroyed and the new surface could not be created
causing rendering to freeze.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4773
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
We had code to do it and it never actually got used correctly. This ensures
that the popup services are attached to the parents so that they get proper
stacking orders when displayed. Additionally, it fixes popups from being
shown as their own windows in Exposé.
If we are clicking through the shadow of a window, we need to take special
care to not raise the old window on mouseUp. This is normally done by the
display server for us, so we need to use the proper API that is public to
handle this (rather than CGSSetWindowTags()). Doing so requires us to
dispatch the event to the NSView and then cancel the activcation from
the mouseDown: event there.
If we closed a key window in response to events, we need to denote another
window as the new key window. This is easiest to do from an idle so that
we don't clobber notification pairs of "did resign"/"did become" key
window.
We have a sorted set of surfaces by display server stacking, so we can
take the first one we come across that is already mapped and re-show it
to become key/main.
If we have server-side decorations we might need to request a layout in
response to the resize notification. We don't need to do this in other
cases because we already handle that in the process of doing the resize
(and that code is that way because of delayed delivery of NSNotification).
If we are using NSWindow titled windows, we don't end up waking up the
frame clock when the window is resized on the display server. This ensures
that we do that after getting a notification of resize.
There are cases we might want to consume a NSEvent without creating a
GdkEvent or passing it along to the NSApplication for processing. This
creates a new value we can use and check against to propagate that without
having to do out parameters at the slightly odd invalid pointer value for
a GdkEvent (similar to how MMAP_FAILED is done).
This can get in the way of how we track changes while events are actively
processing. Instead, we may want to delay this until the next main loop
idle and then check to see if we have a main window as the NSNotification
may have come in right after this.
This one can be used for both premultiplied and non-premultiplied alpha
formats, since alpha is always 255. It is useful for opaque PNG upload
on both cairo and GL renderers.
That way, all permutations are possible. Previously it was only useful
in the cairo renderer, which required rgba8 → premultiplied bgra8, while
the GL renderer required rgba8 → premultiplied rgba8. Now both are
available.
This was only useful when building for AArch32 without -mfpu=neon, on
AArch64 or with -mfpu=neon gcc is smart enough to do the auto-
vectorisation, leading to code almost as good as what I wrote in
1fdf5b7cf8.
It appears that NVIDIA does not implement EGL_EXT_swap_buffers_with_damage
on their EGL implementation, but does implement the KHR variant of it.
This checks for a suitable implementation and stores a pointer to the
compatible implementation within the GdkGLContextPrivate struct.
We want to ensure that we recalculate the sort order of windows before
processing the motion. Generally this would be done in response from the
display server in GdkMacosWindow, but I've seen it possible to race there.
We need to handle the case where we might be racing against an incoming
configure event due to how notifications are queued from the display
server. Rather than calling configure (and possibly causing other things
to move around) this just queries the display server directly for the
coordinates that we care about.
Additionally, we can display:NO as we are in control of all the display
process now using CALayer.
