When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
If a parent doesn't have a window, it means it could have been
dismissed (for example due to a input serial race), but the more recent
popup might win the input serial race and try to map anyway. This would
result in a crash later on when trying to process the placement rule,
as the parent already has no window.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
Move the top-most-popup correctness check to the finish_popup_setup()
function after checking the serial. If we pass the serial check, we
should have reached a state that if there are any popups they should be
the one from the same client.
Also avoid failing a client that correctly set the top-most popup at map
time, but where at the time of processing the top most popup have
already been dismissed by the compositor for some arbitrary reason.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
If a client changes the state of a surface to issue a set_maximize, this
causes apply_pending_state() to be called before mutter has placed the
window.
If the monitor on which the window is to be shown initially is different
from the one where the pointer is placed, this causes the effect to be
played at the wrong location before the window eventually reaches its
location on another monitor.
Force the window to be placed prior to change its state to maximized in
xdg-shell so that mutter won't relocate the window afterwards.
This also avoids sending an xdg_toplevel.configure with a size of 0x0
which would cause the client to initially draw its surface with some
arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=782183https://bugzilla.gnome.org/show_bug.cgi?id=781353
Previously we would bail out early in xdg_toplevel_role_commit() if no
geometry change was set, ignoring the possible min/max size hints
changes.
But setting a min/max size hint without changing the geometry is
perfectly valid, so we ought to apply the min/max changes regardless of
a geometry change.
https://bugzilla.gnome.org/show_bug.cgi?id=782213
If the client doesn't set a geometry using xdg_shell, we'll compute its
geometry based on its surface and subsurfaces.
Yet, we translate that as a window (re)size only when there is a pending
geometry, that we don't have when we computed the geometry by ourself.
Make sure we set the pending new geometry flag when computing the
geometry when it actually changed.
https://bugzilla.gnome.org/show_bug.cgi?id=782213
When the monitor the surface is on has a scale other than 1, the
coordinate of the window menu popup position needs to be scaled, as it
is reported in logical pixels, while the stage is still in physical
pixels.
https://bugzilla.gnome.org/show_bug.cgi?id=776055
Commit 4295fdb892 made us skip focusing
all xdg_popups instead of just non-grabbing ones as intended. This
means that when unmanaging a window we might select a xdg_popup window
to focus (in meta_stack_get_default_focus_window() ) but then since we
don't actually focus it we go on unmanaging the focused window which
triggers an assertion, as it should.
To avoid this and still fixing bug 771694 we can make use of the
MetaWindow->input property for non-grabbing xdg_popup windows since
their semantics, in this regard, are the same as no input X11 windows.
This way, when unmanaging a focused window while a xdg_popup is up,
we'll either give focus to the xdg_popup or not select the popup at
all to be focused if it's non-grabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=775986
When the monitor is scaled (i.e. HiDPI scaling) the placement coordinates
ere still in unscaled xdg_surface window geometry coordinate space when
used to place the window. Fix this by scaling the coordinates by the
monitor scale of the parent toplevel window before using them.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
As meta_window_place_with_placement_rule will trigger a configure event
being sent ensure that the popup is placed on the correct monitor first
to ensure the right scale factor is applied.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=771841
Always use the monitor of the toplevel surface's window, so that the
popup menu and the parent will always have the same scale. This fixes
the dimensions sent in the xdg_popup configure event.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
A xdg_popup, when active, always has a parent surface. However, a popup
created may immediately become invalid, for example when it is not
granted a grab, in which case it won't be assigned a parent since it
will never be mapped.
This case needs to be handled elsewhere, as one cannot assume a
MetaWaylandXdgPoup that is processed (via wl_surface commit handling
etc) will have a parent_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=771495
Implement min/max size request from xdg-shell-v6 and plug it into the
existing code so that windows with fixed size cannot be tiled/maximized
in Wayland just like in X11.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770226
Make sure to always call the parent role commit vfunc, so that they can
handle updating their state properly.
This means other places need to handle the situation where
surface->window is NULL on commit. This may for example happen when the
parent of a modal dialog is unmapped or NULL is attached to a
wl_shell_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Port the xdg_shell implementation to use the unstable v6 protocol. This
includes:
- making xdg_surface a generic base interface for xdg_shell surface
roles
- create a xdg_toplevel role replacing the old xdg_surface
- change the xdg_opup role to be based on xdg_surface
- make xdg_popup not grab by default
- add support for xdg_positioner
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Allow passing parameters (only GObject parameters supported for now) so
that role assignment can affect the paremeters set during construction.
If a role was already assigned when assigning, the passed parameters
are set using g_object_set_valist().
https://bugzilla.gnome.org/show_bug.cgi?id=769936
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
Separate "xdg_surface", "xdg_popup" and "xdg_shell" related functions
into three sections. Prior to this, the "xdg_shell" part was a bit all
over the place.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Add a bridge between the MetaWaylandPopup object and the corresponding
popup surface role. This bridge replaces communicating dismissed and
unmapped popup events.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
A large part of meta_wayland_surface_apply_window_state() was only
relevant for xdg_surface. Make this more obvious by splitting it up,
moving the relevant parts to the relevant roles.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Move xdg_shell related functionality to a new meta-wayland-xdg-shell.c
and wl_shell related functionality to a new meta-wayland-wl-shell.c,
and adapt role object tree.
Common functionality related to the surface being drawn as a
MetaSurfaceActor was moved to a MetaWaylandSurfaceRoleActorSurface role.
The subsurface role GObject is made to inherit the actor surface GObject.
Shell surface hooks (configure, ping, close, popup done) were added to
a MetaWaylandSurfaceRoleShellSurface GObject which inherits the
surface actor role GObject.
The shell surface roles (xdg_surface, xdg_popup, wl_shell_surface) are
made to inherit the shell surface GObject and implement the relevant
API.
https://bugzilla.gnome.org/show_bug.cgi?id=757623https://bugzilla.gnome.org/show_bug.cgi?id=763431
