... and use this check in gdk_gl_context_make_current() and
gdk_gl_context_get_current() to make sure the context really is still
current.
The context no longer being current can happen when external GL
implementations make their own contexts current in the same threads GDK
contexts are used in.
And that can happen for example by WebKit.
Theoretically, this should also allow external EGL code to run in X11
applications when GDK chooses to use GLX, but I didn't try it.
Fixes#5392
When checking characteristics of the context
for downloading, we were using self->context,
even though we are using a possibly different
context for downloading.
Pass the right context along and use it.
File may not have paths, and we should handle
that without incident. While we are at it, add
some logging so GDK_DEBUG=dnd gives us enough
output to see what is going on.
Instead of adding events to the application event queue, dispatch
them directly to the right display. We know this when the event is
to be dispatched.
This is the same as used for the `sendEvent` method in `GdkMacosWindow`.
To achieve this I factored out the generic NSEvent to GdkEvent translation.
We can send an event directly, when we receive it in the GdkMacosWindow
directly from the OS.
By passing the events during a (midal-ish) drag operation to the main loop,
we're able to keep up with what's happening. This allows the internal
drag state (GtkDragSource) to be updated and be done when the drag is
done.
The Drag data should pass through the macos pasteboard system.
We need to provide some pasteboard type. Let's make it a "URL",
which is a pretty generic type anyway.
The handling is done similar to drag targets.
Note that dragging is a modal action on macos: no events
are sent to the main window. This could cause trouble when
we finish the drag, and not finish the gesture in GTK.
This will make it easier to reuse from drag integration so that we don't
require clipboards for everything.
We will need to subclass the pasteboard provider twice, however, both
for clipboard and dragging.
Clang was complaining that we never use the
value stored in mime_type. Just don't store it,
we are only interested in the side-effect
(interning the string).
We have various layers where we store the startup ID for a request,
since this API does not have a GdkToplevel that we can refer about
for the Wayland platform, this is the most obvious candidate to
start untangling these various layers.
Deprecate this call, it is already unused in the gtk/ side.
In the way towards deprecating gdk_display_notify_startup_complete(),
make gdk_toplevel_set_startup_id() on X11 perform this piece of messaging
itself. It should be harmless that the message is emitted twice, if
callers do still use that API.
This call has everything to perform activation as specified by the
xdg_activation protocol, notably a surface to activate as opposed to
gdk_display_notify_startup_complete().
Make activation happen here, so that the surface gets activated when
its gets a startup ID assigned.
The owner_events=TRUE grab makes GDK on X11 see events happening
outside every client window as received on the grab window.
Additionally check that the pointer is inside the grab window
(i.e. it received GDK_CROSSING_NORMAL crossing events for the
core pointer) in order to handle clicks happening outside client
windows.
These new paths are expected to be a no-op on Wayland, and to
also work for touchscreen input on X11, due to emulated pointer
events.
Try to get a native file:// URI instead of any other GVFS
scheme, for interoperability with apps only handling file:// URIs.
This is what GTK3 Nautilus and Thunar do, so apps should be tuned
for this behavior.
See also https://bugzilla.xfce.org/show_bug.cgi?id=13845Fixes: #5422
A Drag surface does not have a parent surface. Therefore, if we initialize
it with one, it's inheriting the frame clock from the parent, but the
drag surface is not linked to the parent. Once the drag surface is destroyed,
it's disposing the frame clock, which results in a "frozen" application.
This is an extra safeguard that avoids grabbing resources longer than
nessecary. It also ensures the resource is removed from the drag,
so it is not freed again.
Currently, the GdkSurfaceX11 implementation relies that the upper
layers hid the surface before destruction, and that no
GdkSurfaceClass.compute_resize happened between them. If these
circumstances happened, there would be a compute_size timeout left
dangling after the surface got destroyed, poking at incorrect data
later on. Something that looks like this was reported in the
recent mutter-x11-frames "SSD frames server":
mutter-x11-frames:423016): GLib-GObject-WARNING **: 19:41:16.869: invalid unclassed pointer in cast to 'GtkWindow'
Thread 1 "mutter-x11-fram" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
1433 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0 g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
#1 0x00007ffff73470ff in g_log (log_domain=log_domain@entry=0x7ffff7f7c4f8 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff7f84da8 "invalid unclassed pointer in cast to '%s'")
at ../../../glib/gmessages.c:1471
#2 0x00007ffff7f72892 in g_type_check_instance_cast (type_instance=type_instance@entry=0x5555558e04b0, iface_type=<optimized out>) at ../../../gobject/gtype.c:4144
#3 0x00007ffff791e77d in toplevel_compute_size (toplevel=<optimized out>, size=0x7fffffffe170, widget=0x5555558e04b0) at ../../../gtk/gtkwindow.c:4227
#4 0x00007ffff7f4f3b0 in g_closure_invoke (closure=0x555555898cc0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffdeb0, invocation_hint=invocation_hint@entry=0x7fffffffde30)
at ../../../gobject/gclosure.c:832
#5 0x00007ffff7f62076 in signal_emit_unlocked_R
(node=node@entry=0x55555588feb0, detail=detail@entry=0, instance=instance@entry=0x55555560e990, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdeb0)
at ../../../gobject/gsignal.c:3796
#6 0x00007ffff7f68bf5 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffe050) at ../../../gobject/gsignal.c:3549
#7 0x00007ffff7f68dbf in <emit signal ??? on instance 0x55555560e990 [GdkX11Toplevel]> (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#8 0x00007ffff7a8de96 in gdk_toplevel_notify_compute_size (toplevel=<optimized out>, size=size@entry=0x7fffffffe170) at ../../../gdk/gdktoplevel.c:112
#9 0x00007ffff7a4b15a in compute_toplevel_size (surface=surface@entry=0x55555560e990 [GdkX11Toplevel], update_geometry=update_geometry@entry=1, width=width@entry=0x7fffffffe220, height=height@entry=0x7fffffffe224)
at ../../../gdk/x11/gdksurface-x11.c:281
#10 0x00007ffff7a4c3b2 in compute_size_idle (user_data=0x55555560e990) at ../../../gdk/x11/gdksurface-x11.c:356
#11 0x00007ffff733f67f in g_main_dispatch (context=0x55555563f6e0) at ../../../glib/gmain.c:3444
#12 g_main_context_dispatch (context=context@entry=0x55555563f6e0) at ../../../glib/gmain.c:4162
#13 0x00007ffff733fa38 in g_main_context_iterate (context=0x55555563f6e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4238
#14 0x00007ffff733fcef in g_main_loop_run (loop=loop@entry=0x5555560874a0) at ../../../glib/gmain.c:4438
#15 0x0000555555557de0 in main (argc=<optimized out>, argv=<optimized out>) at ../src/frames/main.c:68
It perhaps makes sense to warn in these situations, but either way
it sounds like gdk_surface_x11_finalize() could enforce the correct
behavior by ensuring there is no dangling timeouts/data. This commit
does that.
The argument to xdg_activation_token_v1_set_surface is documented to be the
surface requesting the activation, not the surface to be activated, which is
given later when calling xdg_activation_v1_activate.
(c.f. 36cee4bdbc)
Use the same logic as in gdk_wayland_app_launch_context_get_startup_notify_id,
i.e. if we have a surface with focus, set that, otherwise set NULL.
This fixes requesting urgent/focus on wlroots (compositors like Sway, etc.),
which was blocked as the surface requesting the activation didn't have focus.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
By using wl_output_release(), GDK lets the compositor to clean up the
output global more nicely.
For example, currently, most compositors remove the global and then
destroy it later after N seconds expire. With this, the compositor could
experiment with destroying the output global once all its resources are
destroyed.
this is to prevent gdk from causing a segfault, when getting event axes
for events that don't have them (i.e. attempting to get pressure from a
mice input device).
GDK_TOUCH_END deserves the same treatment than GDK_BUTTON_RELEASE, since it's
subject to the same circumstances (popping up a menu on long press would be
immediately dismissed on release if we handled them there). Ideally, we would
want to match releases that we obtained a press for while grabbed, but as
the popup is also dismissed on GDK_BUTTON_PRESS/GDK_TOUCH_BEGIN, there's no
use for this tracking.
And GDK_TOUCH_CANCEL sounds weird as a reason to dismiss popups, just like
crossing events would.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2512
clang complained that we may end up jumping
to the cleanup code without initializing data
in the jpeg code. Always initialize data to
NULL to prevent that eventuality.
GTK knows when a surface is modally blocked and automatically drops
button press and release events, so do not block input in advance
from WM_MOUSEACTIVATE.
This is largely adapted from commit 83027c68f1 ("11: Implement
inhibit_system_shortcuts API"), with similar rationale:
To implement the inhibit_system_shortcuts API on X11, we emulate the
same behavior using grabs on the keyboard.
To avoid keeping active grabs on the keyboard that would affect
other X11 applications even when the surface isn't focused, the X11
implementation takes care of releasing the grabs as soon as the
toplevel loses focus.
Note that Windows has low-level keyboard hooks that could help achieve
the expected behaviour. This is implemented by spice-gtk & gtk-vnc for
example, but correctness isn't obvious. I left a TODO comment.
This patch helps implementing remote desktop widgets with GTK4, since
currently on win32 backend Alt-Tab and such are always left to the
system unless there is keyboard grab (which can't be requested by the
client API anymore, afaict).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
This makes GtkSettings values on X11 match what we get on
other backends.
Reporting size settings in logical pixels (i.e for scale
== 1) is useful for properly supporting mixed-DPI setups.
As X11 doesn't support mixed-DPI setups anyway, XSettings
doesn't bother providing logical values. Thus we scale
from physical to logical values ourselves.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5223
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5230
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
Use newlines rather than spaces to separate file paths (or uri's)
when serializing text/plain files. There isn't a matching
deserializer, so we can do this in isolation. Newlines
seem to make more sense when pasting into a text editor etc.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5240
As documented on MSDN:
> Unlike the WM_LBUTTONUP, WM_MBUTTONUP, and WM_RBUTTONUP messages, an
> application should return TRUE from this message if it processes it.
Empty/zero bounds are sent by the Wayland compositor if there are no
valid bounds to report, e.g. if there are no connected monitors. Report
this to GTK, which uses this to clamp calculated sizes, as INT_MAX, so
that clamping isn't done until there are actual valid bounds to clamp
to.
This fixes clients sometimes shrinking to their minimum size during
hotplugs or after having suspended the session.
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
GTK4 gdk/broadway: correct gdk_broadway_device_query_state() to return pointer coordinates relative to the upper left corner of surface
See merge request GNOME/gtk!5053
As far as I'm aware, these only exist with `gdk_wayland_surface_` names
for historical reasons, before these types were split.
This way, those functions will be able to access members of the
`GdkWaylandToplevel` struct. And it just saves a few lines of code.
There is nothing particularly specific to drawables
in there (and we don't have that concept anymore),
so just name the source file to match the header.
Easier for everybody.
Move the autocleanup declarations into their
respective headers.
While we are at it, correct the autocleanup
declaration for GdkEvent to use gdk_event_unref,
not g_object_unref. Oops
Introduce GDK_DISPLAY_DEBUG() and GDK_DEBUG() and
the helper function gdk_debug_message(). This is
meant to clean up the mess of our current debug
statements which wildly mix g_message, g_print
and g_printerr.
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
Ensures modal window is raised above parent; does return focus to
parent window when transient child window is closed.
That solves problems with overlapped modal window and focus loss in
complex multi window UI.
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.
We failed to handle the toplevel with transient-for case here which could
cause our X/Y calculations to be off in other areas such as best monitor
detection.
We do actually need the parent frame clock here because it is the way we
ensure that we get layout called for our popup surfaces at the same time
as the parent surface.
This doesn't appear to happen much, but if it does it is nice to setup
the window placement initially. Generally, transient-for is set after
the creation of the toplevel rather than here.
The GdkMacosBuffer object already has storage for tracking the damage
region as it is used in GdkMacosCairoContext to manually copy regions from
the front buffer to the back buffer. This makes the GdkMacosGLContext also
use that field so that we can easily drop old damage regions when the
buffer is lost. This happens during resizes, monitor changes, etc.
This helper is useful to ensure we are consistent with how we keep a
window clamped to the workarea of a monitor when placing windows on
screen. (This does not affect snap-to-edges).
Currently, we have all the plumbing in place so that GTK consumes the
startup notification ID when focusing a window through the xdg-activation
protocol.
This however misses the case that a window might be requested to be
focused with no startup ID (i.e. via interaction with the application,
not through GApplication or other application launching logic).
In this case, we let the application create a token that will be
consumed by itself. The serial used is that from the last
interaction, so the compositor will still be able to do focus prevention
logic if it applies.
Since we already do have a last serial at hand, prefer xdg-activation
all the way over the now stale gtk-shell focusing support. The timestamp
argument becomes unused, but that is a weak argument to prefer the
private protocol over the standard one. The gtk-shell protocol support
is so far left for interaction with older Mutter.
If _gdk_macos_surface_move_resize() was called with various -1 parameters
we really want to avoid changing anything even if we think we know what
the value might be. Otherwise, we risk messing up in-flight operations that
we have not yet been notified of yet.
This improves the chances we place windows in an appropriate location as
they don't et screwed up before window-manager placement.
We need to bring the application to the foreground in multiple ways, and
this call to [NSApp activateIgnoringOtherApps:YES] ensures that we become
foreground before the first window is opened. Otherwise we end up starting
applications in the background.
Fixes#4736
If we are double buffering surfaces with IOSurface then we need to copy
the area that was damaged in the previous frame to the back buffer. This
can be done with IOSurface but we need to hold the read-only lock so that
we don't cause the underlying IOSurface contents to be invalidated.
Additionally, since this is only used in the context of rendering to a
GdkMacosSurface, we know the life-time of the cairo_surface_t and can
simply lock/unlock the IOSurface buffer from begin_frame/end_frame to have
the buffer flushing semantics we want.
To ensure that we don't over damage, we store the damage in begin_frame
(and copy it) and then subtract it from the next frames damage to determine
the smallest amount we need to copy (taking scale factor into account).
We don't care to modify the damage region to swapBuffers because they
already have the right contents and could potentially fall into another
tile anyway and we'd like to avoid damaging that.
Fixes#4735
This can be used to lock a surface for reading to avoid causing the
surface contents to be invalidated. This is needed when reading back from
a front-buffer to the back-buffer as is needed when using Cairo surfaces
to implement something similar to BufferAge.
Previously, a single CVDisplayLink was used to drive updates for all
surfaces across all monitors. It used a 'best guess' rate which would
allow for updates across monitors of mixed rates. This is undesirable for
situations where you might have a 144hz monitor as it does not allow for
reaching up to that frame rate.
Instead, we want to use a per-monitor CVDisplayLink which will fire at the
rate of the monitor down to the level of updates we require. This commit
does just that.
When a surface crosses onto a new monitor, that monitor is used to drive
the GdkFrameClock.
Fixes#4732
Using the mode allows better detection of refresh rate and refresh
interval for the CVDisplayLink bridge to GdkFrameClock. Using it can help
ensure that our 144hz displays can actually reach that rather than falling
back to just 60hz.
This will also need future commits to rework the displaylink source to be
per-monitor.
When the fingers are placed on the touchpad, we get a scroll event with
the phase NSEventPhaseMayBegin. We can use this to synthesize an is_stop
event. This results in the scrolledwindow stopping scroll with stop
gestures.
This can cause another warning as well, however, which should be addressed
from #4730.
Fixes#4733
Windows can end up on different monitors despite having a parent or
transient-for ancestor. We want them to be driven by the CVDisplayLink
for the best-monitor, and so this needs to be unshared.
Currently we're using a display link that is for all active displays which
is just the display server trying to find some timings that try to overlap
as many as possible.
That was fine for a prototype, but we really need to do better for
situations with mixed frame rate (such as 60hz and 120hz promotion
displays). Additionally, the 144hz external monitor I have will never
reach 144hz using the current design.
This is just the first step in changing this, but the goal is to have
one of these attached to each GdkMacosMonitor which we can then use to
thaw surfaces specific to that monitor.
We will eventually be needing additional feedback from the display server
which would be nice to keep away from the rest of GdkMacosDisplay for
cleanliness sake. Particularly for feedback from mission control and other
environment factors that requires private API for proper integration.
Instead of performing keyboard layout substitution whenever we find a matching
entry in the registry, first try to load the original layout and only attempt
substitution when that fails.
See #4724
There may be various reasons that an application could need access to the
underlying NSWindow that is being used to display the GdkMacosSurface
contents. This provides a minimal API to do that without exposing our
implementation details through public API.
As our rendering system is likely to change over time, we very much want
to keep GdkMacosView, GdkMacosLayer, GdkMacosTile, and GdkMacosWindow all
private implementation details which are subject to change.
As this is public API, we are a bit long-winded with the name so it is
clear what is being accessed without polluting symbol names with things
like "ns" as we used to.
When using server-side-decorations, we need to avoid potential cycles with
compute-size as it may not have the new sizing information yet. We can
just short circuit during "live resize" to get that effect.
Fixes poor window resizing from top-left on titled windows.
This doesn't give us appropriate results if we use the window delegate.
Instead, we need to adjust the frame at the same time we change the
style mask so that we end up in the same location.
Previously we had issues on macos where the overshoot would keep showing.
To fix this we need to actually use discrete events instead of the
generated deltas from macOS in the scroll wheel case. Additionally, we need
to drop the kinetic momentum events from macOS and rely on the gtk kinetic
events which are already happening anyway. We also need to submit the
is_stop event for the GDK_SCROLL_SMOOTH case when we detect it.
To keep the discrete scroll events correct, we need to alter the hack in
gtkscrolledwindow.c to use the same path as other platforms except for
when a smooth scroll event is in place. In the future, I would imagine that
this falls into the boundary of high-precision scrolling and would share
the same code paths as other platforms.
With all of these in place, kinetic scrolling with overshoot appears the
same on macOS as other platforms.
When creating new windows, it is better if we create them with a slight
offset to where they were created before so that they are visible to the
user separately from what they might be overshadowing.
This broke with the previous fixes for initial window positioning. We need
the initial positioning so that tails will be displayed correctly when the
popover surface is displayed.
If the size changes, we need to relayout the tiles. Otherwise we can keep
using what we had before. Generally, that shouldn't happen, but the
previous check was failing in a number of ways.
