While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
We need to be mapped to have a gtk_surface and thus be able to do
requests on it so we need to save the modal hint and apply it when we
get mapped so that code that sets the hint before showing a window
doesn't get ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=753138
-1 means that we have no specific preference for an initial
fullscreen monitor, and -1 is less than the number of monitors,
so we would end up accessing invalid memory. Prevent that.
https://bugzilla.gnome.org/show_bug.cgi?id=752875
Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
A subsurface positioning operation only takes effect when the parent
surfaces state is applied. If a subsurface is mapped and positioned, but
the parent surface state is not immediately committed, the relative
position of the subsurface is undefined and may be placed incorrectly.
To avoid this undefined state, always request that the parent surface
should be committed after mapping a subsurface so that the position
operation will take effect.
https://bugzilla.gnome.org/show_bug.cgi?id=751098
If a menu was not attached to any widget, we try to calculate its
position given where the grabbed pointer is and what window has its
focus. Previously we failed to do so if a "transfer window" was used
for the grab, and this patch adds a code path that, if the menu window
itself didn't have the grab, look for the transfer window and get the
grab device from there.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
If a position was already explicitly set, don't try to guess the
position of popup menus by looking at the pointer position, just use
the set coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface
was an xdg_surface, we'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749717
The ordering of globals in connection setup under weston
is different from mutter, and we end up creating a the
dnd window before any outputs are present. Don't cause
a critical warning in that case.
Add two new requests to the gtk_surface interface: set_modal and
unset_modal. The server will currently not do anything special with
input focus, and its up to the client to ignore events on the parent
surface.
This commit bumps the gtk_shell interface version to 2. By connecting to
a Wayland server with another gtk_shell interface version any features
depending on the gtk_shell protocol will not be available.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.
For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.
As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
When a window is hidden, its surface and all its roles are destroyed,
if this happens when we already issued a wl_surface_commit and are
awaiting for a frame callback, the clock will remain frozen for the
next time the window is shown.
To avoid this, keep track of the wl_surface_frame() calls issued,
and ensure the clock is thawed after hiding. If we happen to receive
the frame callback, it is just ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=743427
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.
This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.
Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
Use xdg_surface_set_window_geometry() to tell the compositor about the
shadow widths, this makes some gnome-shell/mutter features (edge resistance,
frames around windows in the overview, side maximization, ...) work alright
with GTK+.
In order to add this, some other places in gdkwindow-wayland had to gain
some knowledge about margins:
- xdg_surface_configure() now syncs the shadow after applying the state,
and gdk_wayland_window_set_shadow_width() possibly reconfigures the
window in order to preserve window geometry. This is necessary to keep
shadows in sync with state/geometry changes, as this does not happen
all at once.
- xdg_popups relative to an xdg_surface are shown relative to buffer
coordinates, so the left/top margins must be added there.
https://bugzilla.gnome.org/show_bug.cgi?id=736742
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
Instead of possibly calling wl_surface_commit() out of
GdkFrameClock::after-paint, tick the transient parent clock so ::after-paint
can be eventually run.
This ensures that the subsurface coordinates (considered part of the state
of the parent) aren't committed untimely, and guaranteed to be orderly with
the wl_subsurface-relative state.
This is a gtk-side fix for https://bugzilla.gnome.org/show_bug.cgi?id=738887
cairo_region_copy(NULL) will effectively return an empty region, as this
function is always meant to return valid memory. This however inverts the
meaning of the NULL region and results in entirely non-clickable windows.
We make user facing gl contexts not attached to a surface if possible,
or attached to dummy surfaces. This means nothing can accidentally
read/write to the toplevel back buffer.
A surface may be hidden when a frame is already scheduled, which may cause
crashes on on_frame_clock_after_paint() when calling commit() on a NULL
surface. To fix this, ensure commit_pending is also set to FALSE when the
surface is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=735226
This has been made to work similarly to X11, requests for the data device
contents are notified through GDK_SELECTION_REQUEST events, the data stored
in the GDK_SELECTION property as a reaction to that event is then stored
into the wayland selection implementation, and written to the fd when
requested/available.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
Subsurface position is deemed part of the state of the parent surface, so
ensure wl_surface_commit() happens on the parent surface if none is
scheduled, so the repositioning takes place.
The latest implicit grab serial is used in order to start the compositor
grab, If it belongs to a touch event, remove that touch sequence, as the
rest of the sequence will be gone for good.
This avoids stale sequences (and implicit grab info) after a window is
moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
_gdk_wayland_device_get_button_press_serial() has been replaced by
_gdk_wayland_device_get_implicit_grab_serial(), which takes a touch/pointer
event and figures out the relevant serial, and
_gdk_wayland_device_get_last_implicit_grab_serial() which returns
the most recent serial.
The button press serial was currently used when operating popping up
xdg_shell/surface popups and window menus, so this is now touch aware, of
some sort.
https://bugzilla.gnome.org/show_bug.cgi?id=734374
To all effects each window has its own "root" coordinates system, so set
toplevels at 0,0 in that coordinate system, so root coordinate calculations
are locally right.
https://bugzilla.gnome.org/show_bug.cgi?id=729215
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
Weston releases buffers almost immediately after they're done, which
means that GTK+ doesn't use a temporary surface and instead paints
directly onto the SHM backing store that Weston will use.
Normally, after painting to the temporary surface, GTK+ *replaces*
the existing backing surface with CAIRO_OPERATOR_SOURCE. However,
if we immediately paint to the backing surface, it might have junk
from the last paint in it. So clear out the backing surface whenever
somebody calls begin_paint_region().
Maybe we should just always use the temporary surface like the X11
codepath, since that prevents us from having to do weird things like
this, but oh well.
wl_surfaces can't switch roles, so destroying the xdg_surface but not
the wl_surface means that we could get an error when trying to re-map
the surface.
We could fix this by not destroying the xdg resource and only do it at
finalization time, but it's just as easy to just create a new wl_surface.
Since the xdg roles are a special case of the surface, some compositors
like Weston destroy them automatically when the wl_surface is destroyed.
Thus, we need to destroy these first.
The Wayland compositor is completely allowed to send us configure
events for the same size, and this validly happens if we're changing
states. Fizzle these out.
Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
the menu in a convoluted way: it first grabs another window, shows the
menu window, and then transfers the grab over to the GtkMenu widget.
For normal menubars, this is perfectly fine, as the first window it grabs
is our toplevel, and that gets picked up in our transient path. For
GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
temporary input-only window which it takes the grab on, known as the "grab
transfer window". Since this window isn't a transient-for of our new menu
widget window, the grab isn't noticed when we go to show it, and thus the
menu ends up as a new toplevel.
Add a special hack to GtkMenu and the Wayland backend which lets us notice
this "grab transfer window", and include it in our grab finding path.
It's sort of terrible to have to hack up the widgets instead of just the
backend, but the alternative would be an entirely new window type which is
managed correctly by GDK. I don't want to write that.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
window->x / window->y are in "root window coordinates", e.g. relative
to the topmost toplevel. However, the coordinates in get_xdg_popup are
relative to the passed-in surface, so we need to do the reverse
translation here.
GtkWindow calls set_shadow_width then maps the window, meaning
that we never set the margin. Save it when we set and then set
it when we create the XDG surface.
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
