We might break the loop early, e.g. if we're unmapped before the round
trip finishes, and to avoid the callback to write to invalid stack
memory, destroy the callback so it won't be invoked.
Fixes: #3026
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator()
were only used by by GDK/Win32, and they do not provide performance advantages
in GTK master, so clean up the code a bit by dropping them.
Use gdk_surface_get_geometry() to get the correct x and y coordinates of the
window that we are resizing, so that the window does not reposition itself
automatically at the top-left corner at resizing as we to used hard-code the x
and y coordinates to 0.
By doing so, we ensure that resizes of windows will work on Vulkan renderer, by
first calling gdk_win32_surface_handle_queued_move_resize() before we proceed
as usual
Use the shared function that was added in the previous commit, to simplify
things.
Also make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() back into static functions, since
they are now used only by the code in gdksurface-win32.c
Since we need to deal with queued moves and resizes in the Cairo, GL and Vulkan
draw contexts, and the logic involved in all three of these are largely
similar, add a function gdk_win32_surface_handle_queued_move_resize() that will
handle this, which will be shared between these three types of draw contexts.
Move gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() to gdksurface-win32.c, since these
functions are not only used for Cairo draw contexts, but is also used for GL
draw contexts, and will be used for Vulkan draw contexts.
Don't get the default display when we compute the Aerosnap region, but instead
get it from the underlying GdkSurface that we are using for the computation.
Also, don't unref the monitors that we obtain from the display in the wrong
place, which was why we had crashes whenever we triggered AeroSnap code (and we
are actually not supposed to do that as they are owned by the GdkDisplay that
is owned by the GdkSurface we are using), and this will eliminate lots of
criticals that are spewed as a result.
This check used to read if (grab || device_type != GDK_DEVICE_TYPE_PHYSICAL),
the grab check was only reserved to physical devices, which the current
pointer device definitely doesn't act like. So the condition was "fixed" the
wrong way around, and the latter check is now moot, so the condition should
really go away. We always want to check the new toplevel under the pointer
here.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2970
This allows us to use DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 for the
DPI awareness mode, which will help us to better support use cases with
multiple monitors. This is actualy a more advaned version of the
current PROCESS_PER_MONITOR_DPI_AWARE via using SetProcessDpiAwareness().
Note that this is not enabled by default, but also enabled via using
GDK_WIN32_PER_MONITOR_HIDPI, as in the PROCESS_PER_MONITOR_DPI_AWARE
case.
Note also, that appliation compatibility settings and DPI-awareness
manifests takes precedence over this API call, as before.
Like the other backends, we ought to create our WGL/EGL GL contexts like
the following:
"Create a global GL context that connects all GL contexts on a display
and lets us share textures between them."
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.
We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on
EGL on Windows (ANGLE) so that the red and blue bits won't be displayed
inverted.
Also fix the logic where we determine whether to bit blit or redraw
everything.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direct3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license.
-Build libepoxy on Windows with EGL support enabled.
-Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs
to be set with gl-gles as at least one of the flags.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There are no plans to do this in this
commit.
...EGL support needs to be explicitly enabled during the build of
libepoxy on Windows as it is not enabled by default on Windows.
With this, we can add an EGL renderer for Windows that make use of
Google's libANGLE, which is a library that translates OpenGL/ES calls
to Direct3D 9/11, which will provide better hardware compatibility
on Windows and would act as one of the foundations to resolve issue #105.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
Besides the implicit x/y assumptions, devices don't have axes. Those
are actually provided by the GdkDeviceTool driving the device, and
different tools may have different axes.
It does not make sense to offer this API that can change beneath
someone's feet, we now have gdk_device_tool_get_axes() which is static
to the tool.
Looking at the xf86-input-wacom driver code, this is not even a thing
anymore. Drop this device type, in modern days there's
GDK_DEVICE_TOOL_TYPE_MOUSE for this.
When converting DisplayLink frame presentation times, we need to take into
account the arch-specific types. This tracks changes in GNOME/GLib!1566 so
that precision is not lost.
This is fairly substantial rewrite of the GDK backend for quartz and
renamed to macOS to allow for a greenfield implementation.
Many things have come across from the quartz implementation fairly
intact such as the eventloop integration design and discovery of
event windows from the NSEvent.
However much has been changed to fit in with the new GDK design and
how removal of child GdkWindow have been completely eliminated.
Furthermore, the new GdkPopup allows for regular NSWindow to be used
to provide popovers unlike the previous implementation.
The object design more closely follows the ideal for a GDK backend.
Views have been broken out into subclasses so that we can support
multiple GSK renderer paths such as GL and Cairo (and Metal in the
future). However mixed mode GL and Cairo will not be supported. Currently
only the Cairo renderer has been implemented.
A new frame clock implementation using CVDisplayLink provides more
accurate information about when to draw drawing the next frame. Some
testing will need to be done here to understand the power implications
of this.
This implementation has also gained edge snapping for CSD windows. Some
work was also done to ensure that CSD windows have opaque regions
registered with the display server.
** This is still very much a work-in-progress **
Some outstanding work that needs to be done:
- Finish a GL context for macOS and alternate NSView for GL rendering
(possibly using speciailized CALayer for OpenGL).
- Input rework to ensure that we don't loose remapping of keys that was
dropped from GDK during GTK 4 development.
- Make sure input methods continue to work.
- Drag-n-Drop is still very much a work in progress
- High resolution input scrolling needs various work in GDK to land
first before we can plumb that to NSEvent.
- gtk/ has a number of things based on GDK_WINDOWING_QUARTZ that need
to be updated to use the macOS backend.
But this is good enough to start playing with and breaking things which
is what I'd like to see.
This was preventing any sort of building on macOS, even though the quartz
backend is currently non-functional. Fixing this is a pre-requisite to
getting a new macOS backend compiling.
Run the gdkkeysyms-update.pl script to pick up several
new keysyms:
GDK_dead_lowline
GDK_dead_aboveverticalline
GDK_dead_belowverticalline
GDK_dead_longsolidusoverlay
GDK_Keyboard
GDK_WWAN
GDK_RFKill
GDK_AudioPreset
* GDK_ARRAY_BY_VALUE
#define this to get GArray-like behavior
* gdk_array_splice (v, 0, 0, NULL, 25)
Adding items but passing NULL as the items will zero() them.
* gdk_array_set_size()
A nicer way to call gdk_array_splice()
* constify getters
This is a scary idea where you #define a bunch of preprocessor values
and then #include "gdkarrayimpl.c" and end up with a dynamic array for
that data type.
See https://en.wikipedia.org/wiki/X_Macro for what's going on.
What are the advantages over using GArray or GPtrArray?
* It's typesafe
Because it works like C++ templates, we can use the actual type of
the object instead of having to use gpointer.
* It's one less indirection
instead of 2 indirections via self->array->data, this array is
embedded, so self->array is the actual data, and just one indirection
away. This is pretty irrelevant in general, but can be very noticable
in tight loops.
* It's all inline
Because the whole API is defined as static inline functions, the
compiler has full access to everything and can (and does) optimize
out unnecessary calls, thereby speeding up some operations quite
significantly, when full optimizations are enabled.
* It has more features
In particular preallocation allows for avoiding malloc() calls, which
can again speed up tight loops a lot.
But there's also splice(), which is very useful when used with
listmodels.
This uses the idle-inhibit protocol from wayland-protocols, to attach an
inhibitor to the GdkSurface. The inhibit function can be called as many
times as the user wants, but the uninhibit function MUST be called as
many times to unset the idle inhibition.
This has been tested on Sway.
Not all compositors support _NET_WM_FRAME_DRAWN. In cases
where the compositor doesn't support _NET_WM_FRAME_DRAWN we don't
need to do all the fancy damage tracking and fence watching.
Furthermore, if the compositor doesn't support _NET_WM_FRAME_DRAWN,
it's possible that one frame will start before the previous frame has
made it through the pipeline, leading to a blown assertion.
This commit side-steps the unnecessary code and associated assertion
when _NET_WM_FRAME_DRAWN isn't supported.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2927
If we create an implicit grab on a surface, leave the surface, and
release the button, we would get 2 XI_Leave events, one with mode
XINotifyNormal when the pointer leaves the surface, and another with
mode XINotifyUngrab when the button is released.
Meanwhile, the upper layers rely on crossing events being paired,
and particularly in no crossing event being sent until the implicit
grab is dismissed (either by releasing it, or via more pervasive
grabs).
Ignoring the set of XINotifyNormal events while an implicit grab
is active adapts the X11 backend to this behavior. If the grab were
released or taken away by another grab, a crossing event with one
of the other XINotify*Grab/XINotify*Ungrab will be generated.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2879
Since commit 972134abe4 a frame getting
drawn has three states (with the vendor nvidia driver at least):
1. drawn by gtk waiting on the GPU
2. drawn by GPU waiting on the compositor
3. drawn by compositor
Those three states are encoded in two flags: frame_pending and
frame_still_painting.
frame_pending means step 1 is done, but step 2 and 3 are still
in progress. frame_still_painting means step 2 is still in progress.
After step 1 is finished the surface is frozen until step 3 is finished.
When the compositor notifies gtk it's done with step 3, with a
_NET_WM_FRAME_DRAWN client message, the toolkit thaws the surface to
allow the next frame to proceed.
The compositor sometimes sends gtk a _NET_WM_FRAME_DRAWN client message
between steps 1 and 2. This message should be ignored because it's not
a reply to the current frame.
Unfortunately, gtk currently assumes if it gets a _NET_WM_FRAME_DRAWN
client message while waiting for step 2 that it's actually at step 3,
and proceeds to draw a new frame while the existing frame is still
pending, leading to a blown assertion.
This commit addresses the problem by ignoring _NET_WM_FRAME_DRAWN
client messages from the compositor unless actually expecting one.
Fixes: #2902
Since commit 972134abe4 we now call
glClientWaitSync for the vendor nvidia driver, to know when a frame
is ready for the compositor to process.
If a surface is hidden while a frame is still being rendered by the GPU,
the surface will never produce the damage event the code relies on to
trigger the call to glClientWaitSync. This leaves the fence dangling,
and the next time the surface is shown, it will start a fresh frame
and blow an assertion since the fence from the last frame is still
hanging around.
This commit ensures a frame gets fully wrapped up before hiding a
surface.
Include docstrings and format the list of supported
values better.
Also, add the same warning we have for GTK_DEBUG when
the environment variable is ignored.
This kind of transient state sets the expectative that events update
devices, while it's more accurate to say that devices generate events.
It does not make to expose this function anymore.
Crossing events are now detached from widget state, all tricky consequences
from getting multiple crossing events are now somewhat moot. Resort to sending
all generated crossing events, and drop this barely (ever?) used API.
Commit a0f6ff101e made sure that a
context was bound before calling glClientWaitSync, but it doesn't
check that the context shares objects with the context that created
the fence.
This commit does a little more validation before deciding the current
context is good enough.
Since commit 972134abe4 we now call
glClientWaitSync for the vendor nvidia driver, to know when a frame
is ready for the compositor to process.
glClientWaitSync can be called regardless of which context is currently
bound, but if no context is bound at all, it returns 0 without
doing anything.
This commit checks for that edge case, and ensures a context gets
made current in the event no context is already current, before calling
glClientWaitSync.
When given a 0 timeout, glClientWaitSync is only supposed to return one
of three possible values:
- GL_ALREADY_SIGNALED - fence fired
- GL_WAIT_FAILED - there was an error
- GL_TIMEOUT_EXPIRED - fence hasn't fired yet
In addition, it can also return GL_CONDITION_SATISFIED if a non-zero
timeout is passed, and the fence fires while waiting on the timeout.
Since commit 972134abe4 we now call
glClientWaitSync (with a 0 timeout), but one user is reporting it's
returning some value that's not one of the above four.
This commit changes the g_assert to a g_error so we can see what
value is getting returned.
May help with https://gitlab.gnome.org/GNOME/gtk/-/issues/2858
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.
Use better matching format modifiers/specifiers, initialise some things
which in theory wont be written to because of getters using g_return_if_fail(),
a cast, and gsize as input for malloc because gsize!=glong on 64bit Windows.
GTK 4.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 is a port of !2076 for 4.x.
Scroll events can have history too, so make a
getter that works for both. This drops the
gdk_scroll_event_get_history getter that was
added a few commits earlier, since we now
store scroll history in the same way as
motion history.
Update the docs, and all callers.
There is really no need to store 128 doubles as axes,
ever. We can do just fine with 10. At the same time,
add a GdkAxisFlags member, so we can interpret the
values without having to go chasing the right device
for this information.
Only return one accumulated scroll event per frame.
Compress them by adding up the deltas.
Still missing: a way to capture history, like
we do for motion events.
Fixes: #2800
With the vendor provided Nvidia driver there is a small window of time
after drawing to a GL surface before the updates to that surface
can be used by the compositor.
Drawing is already coordinated with the compositor through the frame
synchronization protocol detailed here:
https://fishsoup.net/misc/wm-spec-synchronization.html
Unfortunately, at the moment, GdkX11Surface tells the compositor the
frame is ready immediately after drawing to the surface, not later,
when it's consumable by the compositor.
This commit defers announcing the frame as ready until it's consumable
by the compositor. It does this by listening for the X server to announce
damage events associated with the frame drawing. It tries to find the
right damage event by waiting until fence placed at buffer swap time
signals.
This commit moves some of the end frame sync counter handling
code to subroutines.
It's a minor readability win, but the main motivation is to
make it easier in a subsequent commit to defer updating the
sync counter until a more appropriate time.
commit 14bf58ec5d dropped support
for using the DAMAGE extension since there was no code that
needed it.
We're going to need it again, however, to address an NVidia
vendor driver issue.
This commit does the plumbing to add it back.
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.
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.
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.)
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.
Scroll events do not have a position, so they shouldn't implement the
GdkEventClass.get_position() virtual function; nor they should have an x
and y fields that never get updated.
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)`.
We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
Without a way to create events, there is no point
in allowing gdk_display_put_event to be used from
the outside. And little good can come out of using
the other apis, so just make them all private.
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.
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).
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.
Don't call into the backends when the input region
or shadow width don't actually change. This avoid
distracting calls in debug logs, and just generally
is the right thing to do.
This is not used anymore now that surfaces are always toplevel in the
semantics of GdkWindow where child windows were available. We can drop
that and simplify the vfunc just a bit more.
Fixes#2765
On X11, shortcuts inhibition is emulated using a grab on the keyboard.
So if another widget ungrabs the keyboard behind our back (for example
when a popup window is dismissed) that effectively disables the effects
of the shortcut inhibition on the surface and we need to update the
shortcut inhibition status accordingly.
Check for "grab-broken" events on the surface and clear existing
shortcuts inhibition for the matching seat, so that the client can be
notified and may decide to re-enable shortcut inhibition if desired.
We pass the GdkEvent as a pointer, because the autogenerated marshallers
don't know how to handle GTypeInstance-derived classes.
Since the GValue box that we use in the marshaller passes the GdkEvent
instance as is, we also need to acquire a reference before invoking the
closure, and release it afterwards, to ensure that the GdkEvent instance
survices the invocation.
Just because we take a ref on a surface does not
guarantee that it is still usable a second later.
Check if its been destroyed in the meantime.
This is breaking the template tests in ci, since
there is no client behind the Broadway server.
The assumption is that the source device in events
is a slave device, so create pointer and keyboard
devices and use them in events.
This fixes the seat test on Broadway.
GDK backends are expected to keep a references on
their surfaces as long as they are associated with
external resources, and drop it in destroy().
This showed up as criticals in the shortcuts test
which manually creates and destroys surfaces.
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).
If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
In the gtk-demo drag-and-drop demo i can't drag anything, all I get
is:
(gtk4-demo:358993): Gdk-CRITICAL **: 09:36:19.617: Surface 0x7e1bb0 has not been mapped in GdkSeatGrabPrepareFunc
This is because GdkX11Drag.ipc_surface is not considered mapped, even
though we called gdk_x11_surface_show() on it, because the
GDK_SURFACE_STATE_WITHDRAWN flag is still set.
I added calls to gdk_synthesize_surface_state() to match what
e.g. show_popup() and gdk_x11_toplevel_present() does.
Tracking of those broke sometime along the gdk cleanups, so we
started missing some GDK_GRAB_BROKEN events from being emitted
(eg. after a button press/implicit grab triggers an active grab).
Implicit grabs are only added if there's no prior grab (either
implicit through other button presses, or explicit), in order to
keep accounting correct, make those prevail.
Conditionally check whether the Vulkan headers version defines
VK_RESULT_RANGE_SIZE, and avoid using it for version >=140. The
following comming in Vulkan-Headers has removed the enum value:
0c5351f5e9 (diff-4febd94c0666d59030d8b1dd20c72403)
When I removed the 0-termination for the entries for
each keyval, I remove the code initializing the key,
but accidentally left the code that adds it to the
array, so gdk_keymap_get_cached_entries_for_keyval
returns one extra, uninitialized value at the end
of the array. Stop doing that.
We currently calling gdk_display_map_keyval up to
once per key event per shortcut trigger, and that function
does an expensive loop over the entire keymap and
allocates an array. Avoid this by caching the entries
in a single array, and have a lookup table for finding
the entries for a keyval.
To do this, change the GdkKeymap.get_entries_for_keyval
signature, and change the ::keys-changed signal to be
RUN_FIRST, since we want to clear the cache in the class
handler before running signal handlers. These changes are
possible now, since keymaps are no longer public API.
In the absence of icon themes (such as in a freshly
created toolbox container), we should not just fall back
to "no cursor", since that makes it hard even to close
the application. Fall back to an included default cursor
of last resort.
Provide a fallback cursor of last resort. Otherwise,
we end up with no visible cursor if there is no
cursor theme installed, wihch is less than helpful.
If the wl_surface receiving touch events is destroyed, we will get no
wl_touch.up event to remove the touchpoint from our internal accounting.
Check for this, and drop touchpoints happening in surfaces that do
disappear during operation.
The api to configure surfaces is now GdkToplevelLayout
and GdkPopupLayout. Unfortunately, there's still quite
a bit of internal use of GdkGeometry that will take some
time to clean up, so move it go gdkinternals.h for now.
The api to configure surfaces is now GdkToplevelLayout
and GdkPopupLayout. Unfortunately, there's still quite
a bit of internal use of GdkGeometry that will take some
time to clean up, so move it go gdkinternals.h for now.
We don't create a grabbing popup if it's not the top most one, as that
is a protocol violation, and complain if anything attempts to do it.
What we didn't do is handle this gracefully in the code that tries to
create said popup.
Fix this by dropping the attempt to show the popup on the floor, instead
of setting various state making it look like it succeeded. This won't
actually fix anything, but it'll result in a bit more accurate warnings
logged, as the state more correctly corresponds to the reality.
When we autohide a popup surface with a grab, hide all other auto hiding
popups up the popup chain. The end result is that when you click outside
a menu with submenus open, the whole menu chain is dismissed.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
For the X11 backend, keep a list of monitors for which the surface
intersects the monitor area.
Whenever the X11 surface is configured, check against the list of
monitors to determine whether it enters a new monitor or if it left a
monitor, to emit the corresponding ::enter/leave-monitor signals just
like a Wayland compositor would.
As monitors can be added, removed or reconfigured at any time, redo
those checks whenever any of these events occur.
Stop rewriting key and focus events on the GDK side.
Instead deliver them as they are, and propagate them
from the root on the gtk side, in gtkmain.c. And
stop complaining about focus events on popups - we
can just ignore them if we have no use for them.
