If we receive multiple SelectionRequest events, we'll end up replacing the
former WaylandSelectionData at a time when an async read has been issued.
This will cause the cancellation of the previous operation.
But the wayland_data_read() callback will attempt to just remove the
current wayland data again on error, which will not be the one we're
cancelling, so the new operation will just be cancelled too.
Also, cancellation is no longer warned about. As the wayland selection
has been replaced at this time, we can just return here.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
This is necessary for the X11 side to catch up, and unset the primary
selection ownership on our window that represents the wayland side in
X11 selection.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
This is necessary for the X11 side to catch up, and unset the selection
ownership on our window that represents the wayland side in X11 selection.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
We may have released the wl_buffer already when doing this, which means
we should not try to access the wl_buffer content.
Regarding the cursor texture this is not an issue since we can just use
the texture created in apply_pending_state().
The hw cursor however will only be realized if the surface is already
using the the buffer (surface->using_buffer == true). This will, at the
moment, effectively disable hardware cursors for SHM buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Don't unset the surface->buffer if the associated wl_buffer object is
destroyed. The MetaWaylandBuffer doesn't really only represent a
wl_buffer object, but also the data (texture) created from the given
wl_buffer. Thus, for example destroying a released SHM wl_buffer should
not destroy the MetaWaylandBuffer instance, because the texture may
still be used.
This commit also fixes a race where calc_showing would hide a window
because, at the time of calculation whether it should be showing, the
surface's buffer had been destroyed as described above.
https://bugzilla.gnome.org/show_bug.cgi?id=762716
In destroy_data_offer() there is code to ensure compatibility when
dragging from a v3 wl_data_device to a v2 one, it's however not checking
correctly that this is the DnD drag source. The other path should be
used otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=762878
For the GDK backend We're using the GdkDeviceManager API, which maps to
Clutter's own device manager API. GDK has now moved to a per-seat device
management model, and deprecated the device manager singleton one.
In order to avoid the deprecation warnings, we'd have to implement a
model similar to the GDK one inside the generic Clutter API, but that
would also require moving all the others backend to it, which is pretty
pointless.
Instead, we can disable deprecation warnings for the
ClutterDeviceManager implementation inside the GDK backend.
This updates config.h.win32.in to be in-sync with the entries that are in
the config.h.in that is generated by the autotools builds. In particular,
for Visual Studio builds, we default to enable all available drivers ("*").
Add an additional MetaWaylandDataSource implementation for primary selection
sources, and methods to set primary selection offers. Primary selection
sets altogether a different channel than the clipboard selection, those don't
cross in any way.
Also, the bridge for the X11 PRIMARY selection atom has been added, which
adds all the necessary handling to translate primary selection both ways
with wayland and X11 applications.
https://bugzilla.gnome.org/show_bug.cgi?id=762560
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762560
It indirectly triggers expensive operations in gnome-shell
(js/ui/keyboard.js), which turns out too expensive if we happen to operate
the shell simultaneously with 2 devices that will trigger the operations
there.
So just rate limit the signal emission, defer to an idle and just emit
the last device gotten. Worst that will happen is that we may possibly
emit the signal on the same device consecutively.
https://bugzilla.gnome.org/show_bug.cgi?id=753527
If a MetaLater callback queued another MetaLater with a scheduling
later than the one currently being invoked, make it so that the newly
scheduled callback will actually be invoked.
The fact that it doesn't already do this is a regression from
cd7a968093.
https://bugzilla.gnome.org/show_bug.cgi?id=755605
Separate from meta-test-runner which runs metatests testing window
manager operations, a new test program (mutter-unit-tests) is
introduced. This is meant to run unit test like tests on various units
in mutter.
An initial test testing the order of MetaLater callback invokation was
added.
https://bugzilla.gnome.org/show_bug.cgi?id=755605
The constraint may be destroyed before the client destroyes the
protocol object, for example if a oneshot constraint was disabled by
alt-tab. Therefore we need to NULL check the constraint in request
handlers and ignore any requests to defunct objects.
The function should return true not only if the actor is being painted
by a ClutterClone, but also if it's inside a sub-graph being painted by
a ClutterClone.
https://bugzilla.gnome.org/show_bug.cgi?id=756371
commit 188752158 changed cogl to stop needlessly creating its own
monitor output configuration when mutter would just soon overwrite
it anyway.
Unfortunately, that commit is causing a crash in some cases because
cogl will now create and later draw to a 0x0 egl surface until mutter
sets the monitor layout.
This commit changes cogl to avoid creating and using a surface, before
it knows how big of a surface to create.
https://bugzilla.gnome.org/show_bug.cgi?id=758073
As of "core: start as wayland display server when
XDG_SESSION_TYPE=wayland" it is no longer possible to run a nested
mutter Wayland session on top of another Wayland session. This patch
adds a command line argument to make it possible to force mutter to
start as a nested compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=758658
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
