If we can't put up a popup because grabbing the pointer fails we
immediately dismiss the popup but the client might have made requests
already, in particular it might have commited the surface and in that
case we should ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=753237
When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.
https://bugzilla.gnome.org/show_bug.cgi?id=753222
This was introduced in commit c6793d477a
to prevent window self-maximisation. It turns out that that bug seems
to have been fixed meanwhile in a different way since the reproducer
in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
fine with this special handling removed.
In fact, failing to set window->fullscreen immediately when loading
the initial set of X properties causes us to create a UI frame for a
window that sets _NET_WM_STATE_FULLSCREEN.
This, in turn, might cause the fullscreen constrain code to fail if
the window also sets min_width/min_height size hints to be the monitor
size since the UI frame size added to those makes the rectangle too
big to fit the monitor. If the window doesn't set these hints, we
fullscreen it but the window will get sized such that the UI frame is
taken into account while it really shouldn't (see the reproducer
above).
https://bugzilla.gnome.org/show_bug.cgi?id=753020
We want to use the Cogl GL3 driver, if possible, and then go through a
known list of Cogl drivers, before giving up and using COGL_DRIVER_ANY.
Based on original patch from Emmanuele Bassi.
We have to create and tear down the whole context when trying
out the drivers though because the extension checks do not happen
until cogl_context_init.
https://bugzilla.gnome.org/show_bug.cgi?id=742678
We want to be able to retrieve the XVisualInfo used when creating the
GL context under GLX and EGL-X11, so that we can use the visual before
we have an onscreen frame buffer.
Since commit 14b0a83f64 we store the
main window monitor instead of computing it every time. This means
that we must now ensure that it's updated before trying to use it
which we do from meta_screen_resize_func() or else we'll crash on an
assertion later on when removing a monitor:
assertion failed: (which_monitor < workspace->screen->n_monitor_infos)
https://bugzilla.gnome.org/show_bug.cgi?id=752674
Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.
Let's fall back to the stringified product code and serial number in
that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752673
There's a chance the icon will be animated, so store the XcursorImages
instead of the individual XcursorImage, and handle that as a nimages=1
special case.
API to "tick" a cursor animation, and retrieve current frame timing
information has been added.
https://bugzilla.gnome.org/show_bug.cgi?id=752342
They otherwise fall through paths that enable bypass_clutter, this
is necessary so they can be picked by captured-event handlers
along the actor hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=752248
The ClutterX11XInputEventTypes enumeration has been unused inside
Clutter for the past 4 years and a half, since we switched to the
XInput 2 API.
The enumeration itself has always been private, and nobody should
have used it in the first place, but if something breaks, we can
revert this commit.
They should be part of the backend-specific API.
The only backend that has an enumeration type is the X11 one, and it's
small, so we can simply put it there.
This is not an ABI change: the backend-specific symbols are still in
the same SO. You'll be required to import clutter-x11.h to have access
to the GType method at the source level, whereas before just importing
clutter.h would have sufficed. The only user of that enumeration was a
function declared in clutter-x11.h, anyway.
We're inconsistently using the NAMESPACE variable instead of passing
the --identifier-prefix and --symbol-prefix command line arguments to
the introspection scanner.
Now that we can warn about deprecated macros, we should finally do it
for the old, non-namespaced key symbol macros that we've been stringing
along since the 1.0 days.
When placing a popup and the legacy transient wl_shell_surface surfaces,
take the current scale of the window into account. This commit doesn't
fix relative positioning in case a window scale would change, but since
the use case for relative positioning is mostly popups, which would be
dismissed before the parent window would be moved, it should not be that
much of a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Make meta_wayland_surface_get_toplevel_window return the top most window
in case its a chain of popups. This is to make all popups in a chain
including the top most surface have the same scale.
The reason for this is that popups are mostly integrated part of the
user interface of its parent (such as menus). Having them in a different
scale would look awkward.
Note that this doesn't affect non-popup windows with parent-child
relationship, because such windows are typically not an integral part of
the user interface (settings window, dialogs, ..) and can typically be
moved independently. It would probably make sense to make attached modal
dialogs have the same scale as their parent windows, but modal dialogs
are currently not supported for Wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
