In gnome-shell, we have a feature where the user can unmaximize windows
by dragging them from the panel above the window. With accurate
anchoring, this looks really weird as the cursor is now "detached" from
the window. Detect this case and put the cursor in the middle of the
window titlebar instead.
This seems to be more accurate with what we currently see in
GNOME. Without having the app expose this information to us, it might be
a better idea to use the default frame style for this information instead.
The cursor was anchored wrongly when trying to unmaximize windows from
dragging them from the top of the screen because of a few think-o's and
some code that forgot to be updated when we moved to the frame rect
coordinate system.
The cursor is still offset for windows that start dragging from the top
panel. This is technically correct, but looks wrong. We'll fix this in
the next commit.
The existing workspace management code is quite hairy, with plenty of
logic inline in all of window.c, workspace.c, and screen.c, making it
hard to understand or make changes to, since you might forget to change
several of the other places the code was around.
Rewrite the internal workspace management logic so that it's
centralized and all in window.c. Document the invariants we need to
maintain, and ensure that these invariants are properly kept, with
asserts in various places.
Extensive testing on gnome-shell did not bring up any issues, and this
is a considerable cleanup.
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
It turns out that Clutter doesn't actually filter NumLock / ScrollLock /
CapsLock from button events due to its terrible event translation code.
Check only the grab mods to check if it's unmodified.
Instead of returning a value based on whether or not we handled it, we
have this logic: either we have taken a grab on the window, in which
case we have a grab op and have handled it ourselves, or we did not take
a grab and *need* to replay the event to the window.
Handle this in events.c by checking the grab operation in the same way
that we check the other grab ops.
This is an accidental regression from 7a109a1. If we mark the event as
handled, then we *need* to set grab_op, or do some other sort of
behavior, since we have a grab.
On X11 this works because only emulated pointer events are listened for. On
wayland, the single touch behavior must be enforced in touch events, ignoring
every other sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
When a Wayland window acks our arrangement and we don't really have
anything to modify, we'll pass a sole flag of META_IS_WAYLAND_RESIZE
to meta_window_move_resize_internal using a garbage rect. The existing
code to calculate the new rectangle couldn't really handle this case,
and so the garbage rectangle accidentally got stored. Revamp the flag
checks to be more clear about it.
This fixes the weird positioning issues that sometimes appear when
resizing weston-terminal among others.
This code was supposed to refresh our default icons when the theme
changed, but it actually was a no-op, since the default icons are cached
in a static variable in MetaUI.
I'm not sure the fact that the fallback icons don't update when the
theme changes is an important enough use case to keep working, but I'm
keeping the skeleton function there in case somebody wants to actually
fix it properly.
This makes sure that we see them for Wayland clients as well, and don't
time out and crash when we're accessing an invalid window / surface.
Spotted-by: Rui Matos <tiagomatos@gmail.com>
Since Wayland configures are more of a hint to the client than anything,
we don't want to save the unconstrained rect when we're just hinting to
the client that it should resize, since it could ignore us. This would
get us stuck in a loop, since meta_window_move_resize_now would use the
unconstrained_rect to resize, and we don't remove the resize from the
queue if we have an outstanding request like that.
This fixes a bunch of traffic / CPU usage when trying to resize
weston-terminal.
For XWayland, we need to make sure to send out mouse events on O-R
windows, otherwise they won't get motion or button events.
The comment mentions being eaten for the compositor, but we already
bypass the compositor for all events that have a window. The return
value just controls whether we pass them to Wayland.
The output_id is more of an opaque identifier for the monitor, based on
its underlying ID from the windowing system. Since we also use the term
"output_id" for the output's index, rename our use of the opaque cookie
"output_id" to "winsys_id".
Some plugins and extensions want to be able to know when the sticky
field of a window changes, so add a property for it and allow them
to connect to the notify::on-all-workspaces signal.
When workspaces-only-on-primary is set and a window is moved back to the
primary, we also move it to the active workspace to avoid the confusion
of a visible window suddenly disappearing when crossing the monitor border.
However when the window is not actually moved by the user, preserving the
workspace makes more sense - we already do this in some cases (e.g. when
moving between primary monitors), but miss others (unplugging the previous
monitor); just add an explicit user_op parameter as used elsewhere to cover
all exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=731760
Remember the last monitor a window was moved to by user action and
try to move it back on monitor changes; this should match user
expectations much better when a monitor is unplugged temporarily.
https://bugzilla.gnome.org/show_bug.cgi?id=731760
When workspaces-only-on-primary is set, a window can be on all
workspaces either because it is on a non-primary workspace, or
because it was explicitly made sticky. Only the latter is reflected
in _NET_WM_STATE, but both will result in a "magic" _NET_WM_DESKTOP,
which we (and probably other WMs) use to set the initial sticky state.
So to avoid confusing other WMs (or ourselves), make sure to only
have _NET_WM_STATE_STICKY reflected in _NET_WM_DESKTOP when unmanaging.
Window state like maximization and minimization should be preserved
over restarts - in a patch review, this would qualify as "needs-work",
so revert the cleanup until the issues are fixed.
This reverts commit dc6decefb5.
Rather than calculate it speculatively with the current properties
which may be too new or too out of date, make sure it always fits
with the proper definition. We update it when we update the toplevel
window for X11, and when a Wayland surface is committed with a newly
attached buffer.
With get_input_region existing, get_input_rect is a misnomer. Really,
it's about the geometry of the output surface, and it's only used that
way in the compositor code.
Way back when in GNOME 3.2, get_input_rect was added when we added
invisible borders. get_outer_rect was always synonymous with server-side
geometry of the toplevel. get_outer_rect was used for both user-side
policy (the "frame rect") and to get the geometry of the window.
Invisible borders were meant to extend the input region of the frame
window silently. Since most users of get_outer_rect cared about the
frame rect, we kept that the same and added a new method, get_input_rect
to get the full rect of the framed window with all invisible borders for
input kept on.
As time went on and CSD and Wayland became a reality, the relationship
between the server-side geometry and the "frame rect" became more
complicated, as can be evidenced by the recent commits. Since clients
don't tend to be framed anymore, they set their own input region.
get_buffer_rect is also sort of a poor name, since X11 doesn't really
have buffers, but we don't really have many other alternatives.
This doesn't change any of the code, nor the meaning. It will always
refer to the rectangle where the toplevel should be placed.
All of the users of get_input_rect don't actually want a synthesized
input rect based off of the current margins. What they really want is
the last-configured size of the toplevel window.
Since we don't properly track this anymore in the generic MetaWindow,
use XGetWindowAttributes to fetch a server-side rectangle. This is a
bad layer violation, but since the window geometry code will have to
be rewritten anyway for the Wayland set_window_geometry, let's just
push a hacky fix for now.
When opening the window menu without an associated control - e.g.
by right-clicking the titlebar or by keyboard - using coordinates
for the menu position is appropriate. However when the menu is
associated with a window button, the expected behavior in the
shell can be implemented much easier with the full button geometry:
the menu will point to the center of the button's bottom edge
rather than align to the left/right side of the titlebar as it
does now, and the clickable area where a release event does not
dismiss the menu will match the actual clickable area in mutter.
So add an additional show_window_menu_for_rect() function and
use it when opening the menu from a button.
https://bugzilla.gnome.org/show_bug.cgi?id=731058
This can happen since we select for events on the root window, and
clients themselves might not select for input, meaning the X server
will bubble up. Just do nothing and ignore the event in this case.
This should hopefully fix some of the
Window manager warning: Log level 8: meta_window_raise: assertion '!window->override_redirect' failed
Window manager warning: Log level 8: meta_window_focus: assertion '!window->override_redirect' failed
spam that people have been seeing.
Since we often call meta_window_move_resize_now immediately after
mapping a window, we need to make sure that the placed coordinates
are saved in the unconstrained_rect. Ideally, placement positions
wouldn't be part of the constraints system, but instead are just
done inside meta_window_move_resize_internal as part of a special
path.
We're still working out the kinks of one large-scale refactor, so
it's best not to do another one while the first is going on. This
would be a great future cleanup, though: untangling constraints
and placement, alongside the force_placement state machine and
friends.
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.
For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.
This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.
Expect some regressions from this. Sorry for any temporary regression
that this might cause.
Now that meta_window_move_resize and friends act in frame rect
coordinates, we need to convert the initial grab_anchor_window_pos
storage to be in frame rect coordinates as well.
This makes Alt+F7 / Alt+F8 work respectively under X11 nested mode.
For the native backend implementation, we'll need a special Clutter
function, so don't implement that for now.
The last commit added support for the "appmenu" button in decorations,
but didn't actually implement it. Add a new MetaWindowMenuType parameter
to the show_window_menu () functions and use it to ask the compositor
to display the app menu when the new button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
The requested_rect is a strange name for it, because it's not actually
the rect that the user or client requested all the time: in the case of
a simple move or a simple resize, we calculate some of the fields
ourselves.
To the MetaWindow subclass implementations, it just means "the rect
before we constrained it", so just use the name unconstrained_rect.
This also makes it match the name of the MetaWindow field.
It looks weird to have Alt+Space pop up under the cursor instead
of the top-left corner of the window, and the Wayland request will
pass through the coordinates as well.
Add it to the compositor interface, and extend the
_GTK_SHOW_WINDOW_MENU ClientMessage to support it as well.
On X, basing the check whether the pointer is on the window on
Clutter events does not work, as the relevant events are handled
by GDK instead.
So add an X-specific window_has_pointer() implementation to also
fix mouse mode when running as X compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=730541
Using clutter_actor_has_pointer() to test whether the pointer is
on the window makes for clean and nice-looking code, but does not
work in practice - ClutterActor:has-pointer is not recursive, so
we miss when the pointer is on the associated surface actor rather
than the actor itself.
Instead, check whether the window actor contains the core pointer's
pointer actor, which actually works.
https://bugzilla.gnome.org/show_bug.cgi?id=730541
Realistically, the user rect contains the unconstrained window
rectangle coordinates that we want to be displaying, in case
something in the constraints change.
Rename it to the "unconstrained_rect", and change the code to always
save it, regardless of current state.
When metacity was originally being built, the purpose of the user
rect was a lot less clear. The code only saved it on user actions,
with various other calls to save_user_window_placement() and a force
mechanism sprinkled in to avoid windows being snapped back to odd
places when constraints changed.
This could lead to odd bugs. For instance, if the user uses some
extension which automatically tiles windows and didn't pass
user_action=TRUE, and then the struts changed, the window would be
placed back at the last place a user moved it to, rather than where
the window was tiled to.
The META_IS_USER_ACTION flag is still used in the constraints code
to determine whether we should allow shoving windows offscreen, so
we can't remove it completely, but we should think about splitting
out the constrainment policies it commands for a bit more
fine-grained control.
https://bugzilla.gnome.org/show_bug.cgi?id=726714
Now that we don't have to regrab to change the cursor, since it's
simply the cursor on the root window, all we have to do is update
the cursor on the screen.
We need the old rect for two purposes: to find the x/y in a resize-only
action, and to pass into the constraints code for nefarious purposes.
The constraints code takes a frame rectangle, so we convert the original
client rect into a frame rect, but never convert it back since it's
unused for the rest of the function.
Instead of playing games with the variables, just have two,
separately-scoped variables. One is the client rect, the other is the
frame rect.
For gravity-based resizing, we need to make sure that the requested
rectangle has the proper x/y position given by the gravity resize,
rather than the bogus root_x_nw / root_y_nw parameter.
Make the test for this more explicit.
With our surface_mapped strategy, implement_showing might not
change whether the window has been shown or not, and thus we
might end up clearing pending_compositor_effect before the window
is mapped.
Only clear pending_compositor_effect when the effect has actually
been used.
Remove extend_by_frame and unextend_by_frame. Use a dumb hack in
window.c to translate into window geometry in back. We'll soon track
all rectangles in MetaWindow in terms of the window geometry.
It's been long enough. We can mandate support for these, at least
at build-time. The code doesn't actually compile without either
of these, so just consider that unsupported.
The Alt+F7 and Alt+F8 keybinds for moving and resizing windows allow you
to move and resize the window off the screen, so allow the same for the
menu items as well, since they're marked with the same accelerator.
https://bugzilla.gnome.org/show_bug.cgi?id=728617
If we start a grab op from a keybind / menu, we'll handle the
ButtonPress and drop the grab then, never giving the window a chance
to handle what it needs to do before the grab is dropped.
This means that if you use Alt+F7 to move a window around, move it
to a side-tiling or maximization area, and then left-click, it will
just hang there in the sky.
The entire point of it was to check whether the window was on the
right screen. Since we don't handle multiple screens anymore, we
don't need to check anything anymore.
We track changes to windows fullscreen state and stacking order
to determine a monitor's in-fullscreen state, but missed the
obvious case of moving a fullscreen window between monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=728395
dx/dy should be against the regular window's rect, and need to
be ignored when we're resizing. Instead, we use gravity to anchor
the window's new rectangle when resizing.
Our focus stealing prevention is still mostly inherited from metacity;
in particular, a (non-transient) window that is not on the current
workspace will not be given focus. This behavior made sense in the
GNOME 2 days, where workspaces were separated much more strictly.
However this is no longer the case in GNOME 3 - activating a launcher
will switch workspaces if necessary, and so will the app switcher.
There is no good reason to not do the same for other user actions
like clicking a URL or activating a search result, so allow activation
of windows on non-active workspaces if a proper timestamp is supplied,
assuming that this is a strong enough indication that we are dealing
with a legitimate user action.
https://bugzilla.gnome.org/show_bug.cgi?id=728018
Effectively we have been accepting CurrentTime timestamps for years,
but still complained about "stupid pagers" when encountering them;
just accept that we will never limit treating 0 timestamps as current
time to pagers.
https://bugzilla.gnome.org/show_bug.cgi?id=728018
Except while reading _NET_WM_WINDOW_OPACITY, opacity is between 0 and 255. With
guint8, we'll get compiler warnings if arbitrary int values are passed.
https://bugzilla.gnome.org/show_bug.cgi?id=727874
The make_toplevel / window_unmanaging interface has never made
a lot of sense to me. Replace it with set_window, which does
effectively the same thing.
It's still not perfect in the case of XWayland, but I don't think
XWayland will ever make me happy.
Really, visible_to_compositor means that the window is shown, e.g.
not minimized. We need to be using a boolean tracking whether we've
called meta_compositor_add_window / meta_compositor_remove_window.
This fixes a jump during window placement when a window appears.
visible_to_compositor should always be in sync with show_window /
hide_window calls, even when unmananging.
This fixes a crash where we call sync_window_state when the window
is unmanaging, since we use visible_to_compositor to determine whether
the compositor will crash.
This is actually wrong; we should be using the knowledge about
whether we have called add_window / remove_window. We'll introduce
this with a new boolean next time.
We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.
With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.
We also kill off active_screen at the same time, since it's
not necessary anymore.
A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.
When I refactored this out into a vfunc, I forgot to change the
code that interprets the result flags to actually respect the
new FRAME_SHAPE_CHANGED result flag.
Since we weren't ever clearing the frame bounds, this meant that
the "shadow clip" wasn't ever updated as a result. Since right now
all Wayland surfaces are considered ARGB32, we always clip shadows
under frames, and thus shadows had this weird "punch-out" from the
first frame shape.
While the ICCCM mandates the use of this, it's not necessary under
a composited environment from my understanding, and it's a flat
out no-op under XWayland.
Looking at the other rootless servers like Xwin/Xquartz, it seems
that they contain code for colormap emulation, but they're actually
never used -- a bug prevents the code from ever being called. Given
that it's been this way since 2003, I'm going to hazard a guess that
not many apps using colormaps. Kill them off.
