Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
When a popup is mapped but will not be the top most popup (for example
the parent is not the current top most popup, or if there already is a
popup mapped but the parent is a toplevel), warn and ignore it instead
of continuing, as continuing would be a protocol violation.
https://bugzilla.gnome.org/show_bug.cgi?id=770745
Add an API that enables an application to, given an exported window
handle, set its own window as a transient of the window associated with
the exported window handle.
https://bugzilla.gnome.org/show_bug.cgi?id=769788
Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The position of each transient-of will be in fake-root coordinate
space; thus we should not accumulate all the positions making it an
offset; each window is already in fake root coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
When using the set transient-for as a popup parent, fetch the effective
toplevel instead, otherwise we will position against the wrong
coordinate.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=760944https://bugzilla.gnome.org/show_bug.cgi?id=755947
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Use of g_signal_handlers_disconnect_by_func() needs to do more work than
necessary to find all the matching handlers. Instead, just hold on to the
signal identifier and remove it directly so we hit the fast path.
Not terribly ground breaking in terms of performance gains, but its done
enough to be worthwhile.
https://bugzilla.gnome.org/show_bug.cgi?id=766049
Don't track all orphaned dialogs globally, as mixing them up with each
other would in most cases trigger errors when we try to pass bogus
values to Wayland requests.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
The naming of pointers to GdkWaylandDisplay's were inconsistent.
Running the following commands in gtk+/gdk/wayland illustrate the
inconsistency:
$ grep -r '\<display_wayland\>' *.[ch] | wc -l
195
$ grep -r '\<wayland_display\>' *.[ch] | wc -l
81
This patch renames all occurrences of "wayland_display" to
"display_wayland". This is also consistent with naming in the X11
backend. A couple of whitespace changes were done as well in places
where the rename was already done, that added line breaks to long lines
that stood out.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
If the configure-event gives us the same size as we had before,
which is common for animation resizes, then try to keep the
existing buffer around. This saves us a memfd_create() syscall
on every frame.
https://bugzilla.gnome.org/show_bug.cgi?id=763350
A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.
https://bugzilla.gnome.org/show_bug.cgi?id=763037
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763001
Use gdk_window_get_effective_toplevel when looking for
a suitable transient parent, to skip over offscreen windows
that we might encounter in the window tree. This fixes
a crash in glade.
https://bugzilla.gnome.org/show_bug.cgi?id=763110
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
According to xdg_shell, an xdg_surface.configure with size 0x0 should
be interpreted as that it is up to the client to set a size.
When transitioning from maximize or fullscreen state, this means the
client should configure its size back to what it was before being
maximize or fullscreen.
This problem currently only occurs on weston because weston sends a
configure with size 0x0 when transitioning back from maximize or
fullscreen.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762713
The staging buffer gets allocated any time begin_paint is called
on the window. This can happen even with an empty paint region,
so we should cope with that situation. At the moment we crash
trying to post a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=762755
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing committed updates: we
can't change what the compositor is actively processing.
The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later. The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.
In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer. The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again. If the client needs to stage new updates, it allocates a
brand new staging buffer, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed buffer back to the client. If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates. This optimization prevents having to allocate
a new staging buffer and the associated cost of back filling
that new buffer with a readback of the committed buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Right now we handle buffer releases coming from the
compositor in a central place. We add a listener when
first creating the shared buffers.
This is problematic because a buffer can only have
one listener on it at once so users of the buffer
can't get notified when it's released.
This commit moves the buffer listener code from the
centrally managed display code to the cursor and window
code.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The client and compositor share access to the window
pixel buffers. After the client hands off (commits)
the buffer to the compositor it's not supposed to write
to it again until it's released by the compositor.
The code tries to deal with this contention by allocating
a temporary buffer and using that in the mean time. This
temporary buffer is allocated by a higher layer of the code
when begin_paint returns TRUE. Unfortunately, that layer of
the code has no idea when the buffer is released, so it ends
up blitting the temporary buffer back to the shared buffer
prematurely.
This commit changes begin_paint to always return FALSE.
A future commit will address the contention problem in
a different way.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
There are a few places where we destroy a cairo surface and
then nullify it. This commit changes those to use
g_clear_pointer instead.
It also drops a cairo_surface_finish call that is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The name surface is really overloaded when dealing
with wayland windows.
To alleviate ambiguity, this commit changes the name
of the "surface" and "subsurface" members to have
a wl_ prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Temp windows without parent are used frequently in our testsuite;
using g_warning on them causes the tests to fail, which is not
useful. Reduce the warning to a g_message.
X11 has the notions of "transient for group", and while it's an ICCCM
violation, it's commonly used and documented that a window manager
would treat a window with transient_for set to None to transient for all
windows of its group.
gtk uses this when an application sets a dialog type window but does not
specify an explicit transient.
While this works on X11, there is no such thing as groups in Wayland and
the closest equivalent which is set_parent() in xdg-shell takes only one
parent. This is what is used for modal dialogs.
To get something similar in behavior to what is available on X11, a
solution is to update the parent() of the dialogs without transient when
the active surface changes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759161
Quite a few applications use GTK_WINDOW_POPUP to create various
temporary windows and place then on screen. That works fine on X11 but
on Wayland there is no global coordinate system for regular surfaces.
If the application is using a gdk temp window and set a parent with
gtk_window_transient_for(), the gdk wayland backend has all it needs to
create a subsurface that can be placed at will by the application.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759738
In most places, we can do with the pointer/keyboard of the default seat
instead of the client pointer. We can also remove some code from
gdk_input_init() because we know for sure there's no floating devices to
care about here.
Gdk Wayland backend walks up the transient windows tree, but does not
check for cycles when doing so.
As a result, if two or more windows are transient to each other, the
Wayland gdk backend will enter an infinite loop.
While this is clearly a bug in the application, gtk+/gdk should be more
robust and handle such errors more gracefully.
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
