Some applications need to access gdk_quartz_window_get_nsview,
gdk_quartz_window_get_nswindow, and gdk_quartz_event_get_nsevent
so move these from the private gdkquartz-gtk-only.h to a new
header gdkquartz-cocoa-access.h. Don't include this header in
gdkquartz.h so that user code that doesn't need to access these
functins isn't required to compile with Objective C/C++.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/1737
We can just group the code for the desktop GL codepath and the EGL
codepath a bit so that we can just have a single location where we
return TRUE upon a successful setup of our WGL/EGL context, and avoid
the C4715 warning that is considered an error when building with
GLib-2.68.x or later using Visual Studio, when we are building without
EGL support.
The condition we check for to catch X servers going away
may not be accurate anymore, and the warning shows up in
logs, causing customers to be concerned. So, be quiet by
default, unless the user explicitly asked for a message.
When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
The preprocessor directives for proper OS version support are missing
their last digit, rendering the checks defunct.
Improves on https://gitlab.gnome.org/GNOME/gtk/-/issues/3592 but does
not fully fix as other issues have surfaced down the line.
... until all globals have been received.
The dependency tracking introduced in 4e9be39518 only allows to
specify required globals and processes the closures as soon as
the requirements have been met. There are, however, also optional
dependencies - most notably the primary_selection protocol.
Currently we rely on the fact that compositors like Mutter announce
it before `wl_seat`, even though the order is not specified in
the spec.
Process globals closures only after all globals have been announced,
so optional dependencies can be accommodated.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/3791
The DnD code for X11 adds the composite overlay window (aka COW) to the
cache.
Yet the X11 requests to get and release the COW may trigger XErrors that
we ought to ignore otherwise the client will abort.
Fixes: #3715
Partially fixes issue #2191 regarding switching to another app while
hovering a stylus over a drawing tablet causes subsequent mouse
clicks in the app to be ignored. I was not able to reproduce the
other behavior described in #2191 concerning tiling a window.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
This is useful when clients use subsurfaces independently of GDK.
For example if a client creates a subsurface that covers a GdkWindow
entirely. If this subsurface is opaque, Wayland compositors may not
emit callbacks for the surface of the GdkWindow any more.
Adding the covering subsurface via this new API ensures the
GdkWindow will continue to update in this case.
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.
This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.
Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
When destroying a wl_surface (e.g. when a window or menu is closed), the
surface may continue to exist in the compositor slightly longer than on
the client side. In that case, the surface can still receive input
events, which need to be ignored gracefully.
In particular, this prevents segfaulting on wl_surface_get_user_data()
in that situation.
Reported in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3296
The same issue for pointers/keyboards was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=693338
and fixed with in
bfd7137ffb3625f17857a8fc099a72
Intel OpenGL drivers have an issue where the results of a series of
glBlitFramebuffer() can delay updating the display, when we use GDK_GL=always,
which is manifested when attempting to enter text in text boxes.
This attempts to work around this issue by requiring a glFlush() call and a
retry to the same glBlitFramebuffer() calls to avoid delays in keystrokes when
using GDK_GL=always and when not using libANGLE OpenGL/ES emulation, when an
Intel OpenGL driver is being used.
Special thanks to Lukas K. for the analysis and coming up with a workaround,
which this patch builds upon.
Fixes issue 3487
Makes event listeners active explicitly if supported; corrects
handling for deleted surfaces preventing javascript errors in
accessing deleted objects; makes event identifiers unique for
broadwayd when executing in Chrome on Android.
Partially fixes#1493
In pointer_surface_update_scale(), only rescale the cursor surface when
the scale has actually changed and the cursor is on at least one output.
fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3350
Right now, this issue is not completely understood, so it might also
involve some questionable handling of cursor surface by sway/wlroots.
However, irrespective of that issue, this patch avoids unnecessary calls to the
compositor, and there should be no drawback: Whenever the pointer enters
a new output, pointer_surface_update_scale() will be called again, such
that correct scaling of the cursor is still ensured.
There is a slight difference: When the cursor leaves the last output,
previously the image was reset to scale factor 1. Now, it keeps whatever
was last. That might be more sensible than the previous behaviour,
assuming that it's likely that when the cursor enter an output again, it
has the same scaling. Alternatively, if one cares about resource usage
at this level, it might make more sense to destroy the surface then
rescaling to 1.
In gdkdevice-win32.c we are interested in knowing which window
receives mouse input at a specific location.
Only WindowFromPoint is the right API for the task, other API's
(such as (Real)ChildWindowFromPoint(Ex)) have shortcomings because
they are really designed for other purposes. For example, only
WindowFromPoint is able to look through transparent layered windows.
So even if we want to find a direct child we have to use
WindowFromPoint and then walk up the hierarchy.
Fixes: #370, #417
See: !2767
There is some bug somewhere where the geometry ends up being correct.
Mutter didn't handle this gracefully, and is to be changed to simply
respect the protocol and error out the client that sends bogus data.
Prepare for this by instead of sending bogus data, complain loudly if it
would happen dropping the invalid geometry on the floor instead of
sending it.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1527
When setting a window's background to ParentRelative on X11, the window
depths must match to avoid a BadMatch error. Query the X server for the
parent window rather that relying on the parent passed to
gtk_window_new() to prevent crashes with reparented windows.
Fixes: #3288
Remove all of the selectors. They just set the passthrough anyway so
there's not much point to maintaining them and they weren't the
complete set of possible selectors.
Additionally to gtk_primary_selection, the gtk-private predecessor,
support the upstream unstable protocol.
This allows the primary selection to work on Kwin and potentially
other compositors, as well as dropping the private version eventually.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2591
When a fixed size is active (e.g. the window is maximized),
gtk_window_resize() shouldn't take immediate effect, so the request was
dropped. This made GTK unhappy if this happened, it will freeze updating
the window until it received the new size it demanded.
Handle this by being nice and emitting a dummy GDK_CONFIGURE event with
the old size where we previously ignored it. It won't resize the window
immediately, so it shouldn't have a visible effect, and the size GTK
requested is still saved away for when the window is unmaximized, but
emitting the event will make GTK receive the event it expects.
We still drop the request on the floor, e.g. if we still haven't seen
the initial configuration, just as we do when actually doing the resize.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
This device may go away, which means we have a pointer to a possibly
stale object. Keep a reference here, and let future events bring this
accounting up-to-date when the mouse pointer is next updated via other
device.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/855
When using the gdk_display_close(), the handle to the Wayland compositor was not released.
This could cause the consumption of all available handles, preventing other processes from accessing the display.
Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.
Signed-off-by: Julien Ropé <jrope@redhat.com>
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
Previously, a GDK application handled the Wintab cursors (stylus,
eraser, etc.) only during app initialization. If new cursors were
recognized by Wintab during app execution, the app would not know
about them.
This fix still handles Wintab cursors known during app initialization.
In addition, when Wintab recognizes new cursors and notifies the app
via a WT_CSRCHANGE message, the app handles the new cursors, creating
new Wintab device objects for them.
Closes#1549
This may need to be changed next year, it depends on what Apple
decides to do with version numbers going forward.
Also updated GdkOSXVersion to include Catalina and Big Sur.
Instead of using the incomplete GTK-internal emulation, use the WM_CHAR
messages sent by Windows. Make the IME input method the default for all
languages on Windows.
When a window receives a resize request, it might ignore this new size and
use the compositor's size hints instead to restore to floating mode.
This commit changes that behaviour in that a window will always prefer
the manually resized dimensions over the compositor's hint.
This makes the desired behaviour explicit, and matches the behaviour
seen with Meson, where "external : false" is the default.
Before GNOME/glib!1468, not passing --internal to the resource compiler
meant "no special export attribute, do what you would normally do",
so these symbols were not exported due to our global use of
-fvisibility=hidden.
However, since GNOME/glib!1468, not passing --internal to the resource
compiler results in the symbols being decorated with G_MODULE_EXPORT,
which overrides -fvisibility=hidden. This was necessary because Windows
DLLs normally behave a bit like the equivalent of ELF libraries with
-fvisibility=hidden.
Signed-off-by: Simon McVittie <smcv@debian.org>
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/2919
Input devices such as stylus pens have additional axes besides (x,y)
coordinates. In order for these devices to work properly, their additional
axes need to be mimicked from the physical device to the associated
virtual pointer when they become active.
If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).
This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.
Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
The Quartz Window Manager adds to the Windows menu all NSWindows with
titles. Since we assign a default title to all windows that produced a
rather cluttered Windows menu containing among other things dialogs.
Setting aside that dialogs don't belong in the Windows menu, if
a dialog was hidden for reuse instead of destroyed it would persist in
the Windows menu and if clicked there would show, but because it wasn't
running wouldn't respond to events and so couldn't be hidden again and
would remain on top of its parent window.
Ref: https://bugs.gnucash.org/show_bug.cgi?id=797807
Fix scheduling of the frame clock when we don't receive "frame drawn"
messages from the compositor.
If we received "frame drawn" events recently, then the "smooth frame
time" would be in sync with the vsync time. When we don't receive frame
drawn events, the "smooth frame time" is simply incremented by constant
multiples of the refresh interval. In both cases we can use this smooth
time as the basis for scheduling the next clock cycle.
By only using the "smooth frame time" as a basis we also benefit from
more consistent scheduling cadence. If, for example, we got "frame
drawn" events, then didn't receive them for a few frames, we would still
be in sync when we start receiving these events again.
When an animation is started while the application is idle, that often
happens as a result of some external event. This can be an input event,
an expired timer, data arriving over the network etc. The result is that
the first animation clock cycle could be scheduled at some random time,
as opposed to follow up cycles which are usually scheduled right after a
vsync.
Since the frame time we report to the application is correlated to the
time when the frame clock was scheduled to run, this can result in
uneven times reported in the first few animation frames. In order to fix
that, we measure the phase of the first clock cycle - i.e. the offset
between the first cycle and the preceding vsync. Once we start receiving
"frame drawn" signals, the cadence of the frame clock scheduling becomes
tied to the vsync. In order to maintain the regularity of the reported
frame times, we adjust subsequent reported frame times with the
aforementioned phase.
GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is
deprecated as the ARB version has been merged into OpenGL 3.0 as well as
OpenGL ES 2.0, and provides laxer requirements.
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.
Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
When the application does not receive "frame drawn" signals we schedule
the clock to run more or less at intervals equal to the last known
refresh interval. In order to minimize clock skew we have to aim for
exact intervals.
(cherry picked from commit f5de46670b)
We try to step the frame clock in whole refresh_interval steps, but to
avoid drift and rounding issues we additionally try to converge it to
be synced to the physical vblank (actually the time we get the
frame-drawn message from the compositor, but these are tied together).
However, the convergence to vsync only really makes sense if the new
frame_time actually is tied to the vsync. It may very well be that
some other kind of event (say a network or mouse event) triggered
the redraw, and not a vsync presentation.
We used to assume that all frames that are close in time (< 4 frames
apart) were regular and thus tied to the vsync, but there is really no
guarantee of that. Even non regular times could be rapid.
This commit changes the code to only do the convergence-to-real-time
if the cause of the clock cycle was a thaw (i.e. last frame drawn and
animating). Paint cycles for any other kind of reason are always
scheduled an integer number of frames after the last cycle that was
caused by a thaw.
(cherry picked from commit 91af8a705b)
When we get to a paint cycle we now know if this was caused by a
thaw, which typically means last frame was drawn, or some other event.
In the first case the time of the cycle is tied to the vblank in some
sense, and in the others it is essentially random. We can use this
information to compute better frame times. (Will be done in later
commits.)
(cherry picked from commit 82c314f1af)
When we run the frameclock RUN_FLUSH_IDLE idle before the paint,
then gdk_frame_clock_flush_idle() sets
```
priv->phase = GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT
```
at the end if there is a paint comming.
But, before doing the paint cycle it may handle other X events, and
during that time the phase is set to BEFORE_PAINT. This means that the
current check on whether we're inside a paint is wrong:
```
if (priv->phase != GDK_FRAME_CLOCK_PHASE_NONE &&
priv->phase != GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS)
return priv->smoothed_frame_time_base;
```
This caused us to sometimes use this smoothed_frame_time_base even
though we previously reported a later value during PHASE_NONE, thus
being non-monotonic.
We can't just additionally check for the BEGIN_PAINT phase though,
becasue if we are in the paint loop actually doing that phase we
should use the time base. Instead we check for `!(BEFORE_PAINT &&
in_paint_idle)`.
(cherry picked from commit a36e2bc764)
The included fribidi header is not used in gdkkeys-wayland.c and already
included in gdk.c which causes linker issues due to the header defining
a global variable.
A call to frame gdk_frame_clock_get_frame_time() outside of the paint
cycle could report an un-error-corrected frame time, and later a
corrected value could be earlier than the previously reported value.
We now always store the latest reported time so we can ensure
monotonicity.
(cherry picked from commit a27fed47e0)
In commit c6901a8b, the frame clock reported time was changed from
simply reporting the time we ran the frame clock cycle to reporting a
smoothed value that increased by the frame interval each time it was
called.
However, this change caused some problems, such as:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1415https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1416https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1482
I think a lot of this is caused by the fact that we just overwrote the
old frame time with the smoothed, monotonous timestamp, breaking
some things that relied on knowing the actual time something happened.
This is a new approach to doing the smoothing that is more explicit.
The "frame_time" we store is the actual time we ran the update cycle,
and then we separately compute and store the derived smoothed time and
its period, allowing us to easily return a smoothed time at any time
by rounding the time difference to an integer number of frames.
The initial frame_time can be somewhat arbitrary, as it depends on the
first cycle which is not driven by the frame clock. But follow-up
cycles are typically tied to the the compositor sending the drawn
signal. It may happen that the initial frame is exactly in the middle
between two frames where jitter causes us to randomly round in
different directions when rounding to nearest frame. To fix this we
additionally do a quadratic convergence towards the "real" time,
during presentation driven clock cycles (i.e. when the frame times are
small).
(cherry picked from commit 9ef3e70040)
On my X11 + nvidia setup gnome-shell doesn't report presentation times.
However it does report refresh rate. We were mostly using this in our
calculation except when computing predicted presentation time, were
it fell back on the default 60Hz.
(cherry picked from commit f1215d2d77)
If the tablet gets removed/freed while there are pad events in flight,
we leave a dangling pointer from the pad to the tablet, which may
lead to invalid reads/writes when handling the pad event(s).
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2748
Reading form the back buffer is not allowed on software renderers,
and this is reported by the buffer age, so reading from GL_BACK
should not be done when the age is 0
Closes#64
Instead of hardcoding gtk-xft-antialias, use SPI_GETFONTSMOOTHING to
determine whether antialiasing is enabled.
Make gtk-xft-rgba query more complex - try to determine display
orientation, then use that to rotate subpixel structure. This
won't help with monitors that have naturally vertical subpixels,
but should improve things for monitors that are rotated (as long
as Windows display settings are adjusted accordingly).
Partially fixes#1774
This reverts commit fc2008f240.
Turns out, we *don't* have code to maintain Z-order. Restacking
code is not doint that, it just enforces a few weird Z-order-related
behaviours.
The order in which the resources get embedded matters for reproducible
builds. In the Meson build system, gen-gdk-gresources-xml already sorts
the list, but in the Autotools build system they were previously taken
in readdir() order.
Signed-off-by: Simon McVittie <smcv@debian.org>
