The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.
This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
In case a window is hidden when we're ordered to make it transient to
a different parent we must re-evaluate its visibility status or we'll
get into an inconsistent state where the parent is visible and the
child isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=759297
This seems like a more generally useful and intuitive behavior. Note
that, in X sessions, this is what already happened in practice since
meta_display_begin_grab_op() calls meta_window_grab_all_keys() which,
on X11, does meta_window_focus().
https://bugzilla.gnome.org/show_bug.cgi?id=756789
Don't update the stack until after setting the window->transient_for
field. Updating before will cause the stack transient-for constraint to
be missing until the next time constraints are applied.
https://bugzilla.gnome.org/show_bug.cgi?id=755606
Wine removes the minimize func from its Motif hints on full-screen
windows, because, as the Win32 API literally says, the minimize button
is indeed not visible on full-screen windows.
Given that this code was added to prevent minimizing a panel by
accident, I don't necessarily think that it's relevant anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=758186
Unsetting it in meta_display_handle_event() will make the pointer
emulation checks fail on TOUCH_END event handlers across clutter
actors, the sequence should still be considered as pointer emulating
at that time.
As we don't have a way to hook this post clutter event handling,
instead unset/reset it lazily on the next pointer emulating TOUCH_BEGIN
event, the checks would already fail on other sequences, even if the
pointer emulating touch ended earlier. The only extra thing we need
to take care about is sequence collision, at which point it's safe to
just unset the stored sequence if its new incarnation isn't flagged/
deemed as pointer emulating.
https://bugzilla.gnome.org/show_bug.cgi?id=756754
When managing window, we queue showing the window.
Under wayland, if we commit surface quickly enough,
the showing is unqueued and commit procedure takes care
of mapping and placing the window. In the oposite case,
queue is processed before client sets all we need and
then we have wrong size of window, which leads to broken placement.
Therefore force placement in queue only if the window should already
be mapped. If it is not mapped, we don't care where it is anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751887
We have been ignoring those buttons since 3.16 after they had been
broken in the default theme for a couple of versions. As nobody
appears to miss them, it's time to remove them for good.
Displaying all Wayland windows with the XID of 0x0 makes it hard
to figure out what is going on ... use the recently-added
window->stamp to show Wayland windows as W1/W2/W3...
This commits refactors cursor handling code and plugs in logic so that
cursor sprites changes appearance as it moves across the screen.
Renderers are adapted to handle the necessary functionality.
The logic for changing the cursor sprite appearance is done outside of
MetaCursorSprite, and actually where depends on what type of cursor it
is. In mutter we now have two types of cursors that may have their
appearance changed:
- Themed cursors (aka root cursors)
- wl_surface cursors
Themed cursors are created by MetaScreen and when created, when
applicable(*), it will extend the cursor via connecting to a signal
which is emitted everytime the cursor is moved. The signal handler will
calculate the expected scale given the monitor it is on and reload the
theme in a correct size when needed.
wl_surface cursors are created when a wl_surface is assigned the
"cursor" role, i.e. when a client calls wl_pointer.set_cursor. A
cursor role object is created which is connected to the cursor object
by the position signal, and will set a correct texture scale given what
monitor the cursor is on and what scale the wl_surface's active buffer
is in. It will also push new buffers to the same to the cursor object
when new ones are committed to the surface.
This commit also makes texture loading lazy, since the renderer doesn't
calculate a rectangle when the cursor position changes.
The native backend is refactored to be triple-buffered; see the comment
in meta-cursor-renderer-native.c for further explanations.
* when we are running as a Wayland compositor
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Before, it used to be in the screen, but now,
meta_cursor_reference_from_theme can never fail. Move it to where we
load the images from the cursor name.
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
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
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
Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
A much less hacky version of maximize / unmaximize is reimplemented
in terms of this, but it could also eventually be used for fullscreen /
unfullscreen, and tile / untile.
The only time we ever execute this code is when we're minimizing or
hiding a window, in which case we should respect stacking order.
This fixes weird "bugs" where windows from the same app magically pop up
over other windows.
This is an extremely niche feature, and conflicts with the rest of our
interface being consistent about not allowing resizing while tiled or
maximized.
A window may be hidden even if not minimized itself, for instance
when an ancestor is minimized. As meta_window_focus() will refuse
to actually focus the window in that case, don't pick it in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=751715
Going from fullscreen to unfullscreen involves a frame border size, so
in order to properly interpret the saved rect size, we need to make sure
that the frame borders are fully up to date.
The "calc showing" operation is queued in a few places alongside MetaWindow
creation, we should be ignoring these until there is a buffer to show.
https://bugzilla.gnome.org/show_bug.cgi?id=750552
window->is_alive isn't initialized explicitly so it defaults to FALSE
meaning that if the first ping fails we'd short circuit and not show
the delete dialog as we should.
We could initialize the variable to TRUE but in fact we don't even
need the variable at all since our dialog management is enough to
manage all the state we need, i.e. we're only interested in knowing
whether we're already displaying a delete dialog.
This does change our behavior here since previously we wouldn't
display the dialog again if the next ping failed after the dialog is
dismissed but this was arguably a bug too since in that case there
wouldn't be a way to kill the window after waiting for a while and the
window kept being unresponsive.
https://bugzilla.gnome.org/show_bug.cgi?id=749711
When running as an X11 compositor we do this for every event we see on
the X event stream. As a wayland compositor we don't go through that
code path but since we see all events we can easily do this on motion
events.
In fact, we don't even need this caching when we're a wayland
compositor since we can always find where the pointer is without a
round trip but we're sharing the current monitor logic with the X
path so let's keep it as is for now.
https://bugzilla.gnome.org/show_bug.cgi?id=748478
The existing private get_monitor_neighbor() function returns a
MetaMonitorInfo, which is private as well. Add a public wrapper
that returns a monitor index instead, as we do for other public
monitor-related methods.
https://bugzilla.gnome.org/show_bug.cgi?id=633994
Since the frame is the window that's redirected, there's no reason for
it to match the root window. There *is*, however, a big incentive to
match the window's visual, since not doing so might trigger automatic
redirection.
On a specific platform, we construct a depth-32 root window, and stick a
depth-24 child window inside it. The frame ends up being created
depth-32, not depth-24, so we get automatic redirection.
clutter currently never emits activated or deactivated signals on
the stage object when using the EGL backend. Since the stage never
gets activated, accessibility tools, like orca, don't work.
This commit makes mutter take on the responsibility, by tracking
when the stage gains/loses focus, and then synthesizing stage
CLUTTER_STAGE_STATE_ACTIVATED state events.
A limitation of this approach is that clutter's own notion of
the stage activeness won't reflect mutter's notion of the
stage activeness. This isn't a problem, in practice, and can
be addressed in the medium-term after making changes to
clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=746670
With all input events being handled through clutter, this only confuses
things, and most nominally, coerces touch events through places we didn't
intend to, like the window frame.
This makes again all touch events only handled in the passive grab on X11,
while the rest stays pointer (emulated) only.
https://bugzilla.gnome.org/show_bug.cgi?id=745335
In order to switch to the correct surface actor scale given the monitor
the surface is on, without relying on the client committing a new state
given some other side effect, sync the surface actor state when the main
monitor associated with the corresponding window changed.
https://bugzilla.gnome.org/show_bug.cgi?id=744933
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
We're locked to frame sync anyway, so it doesn't make sense to try to
redraw early. In casual testing, this seems to actually make things
faster, as well.
When looking for space to place a new window, other non-minimized
windows on the same workspace should be taken into account. However
the current check does not work correctly when the placed window is
located on all workspaces, so handle that case explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743217
When running as a dispay server pointer barriers are a server side
feature and requires no client interaction of any sort. This patch
implements pointer barriers that can be used when running as a display
server on the native backend. Running as a display server using the X11
backend is currently not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
This patch removes the X11 specific code from MetaBarrier and creates an
abstraction layer MetaBarrierImpl. The existing X11 implementation is
moved to a new GObject MetaBarrierImplX11 implementing the abstract
interface MetaBarrierImpl which is instantiated by MetaBarrier when
supported.
While at it, move it to backends/ and properly name the files.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
MetaKeyCombo is about the *unresolved* keybinding, which can either be a
"keysym" (<Ctrl>F) or a "keycode" (<Ctrl>0x21). When we resolved the
keysym to a keycode, we stuffed it back in the same MetaKeyCombo, which
confused about what the "keycode" field was for. Thus, we often stomped
on the user's explicit choice if they chose a keycode binding value.
To solve this, create a separate structure, the "devirtualized key combo"
or MetaKeyDevirtCombo, which contains a resolved keycode from the
keysym, and a devirtualized modifier mask. The MetaKeyCombo is now
always a "source" value, and the MetaKeyDevirtCombo is now always what
the user chose.
This also lets us significantly clean up the overlay and ISO key binding
paths.
The reason MetaKeyCombo has a keycode value at all is *not* to store the
devirtualized keycode from the keysym, but instead to allow people that
type in "0x55" into the preference. Everything except the overlay-key
respected this. Make the overlay-key binding respect this.
Break down the beautiful core/ui abstraction barrier by inserting
a pointer to MetaWindow into a MetaUIFrame. I'm a scoundrel, I know.
We'll use this very soon to destroy meta_core_get.
Rest in peace you magnificent format, love-child of arcane X11 drawing
API and markup craze, you will not be missed.
We do remember however the bravery of a many men and women, who fearlessly
descended into the guts of your intrinsics and turned ugliness into beauty;
their work will still be spoken of when you will long have been forgotten.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
This reverts commit ec8ed1dbb0.
1) It turns out to add a momentary flicker from the transition
between the login screen and user session
2) It actually isn't needed anymore since bug 733026
https://bugzilla.gnome.org/show_bug.cgi?id=740377
The set/unset branches of meta_display_update_pointer_emulating_sequence()
have been split and put directly where it makes sense. The pointer emulated
sequence will be updated before processing the CLUTTER_TOUCH_BEGIN, and
after processing the CLUTTER_TOUCH_END, this way the checks on this hold
true during all the sequence lifetime.
https://bugzilla.gnome.org/show_bug.cgi?id=738411
Returning FALSE here gets the button release event propagated to the
client on wayland, which is unexpected after xdg_surface.move/resize()
have been called.
https://bugzilla.gnome.org/show_bug.cgi?id=738888
Commit 2f9c601 accidentally changed the logic here, changing the grab
behavior when not using raise-on-click. Fix this.
Spotted-by: Adam Goode <adam@spicenitz.org>
Fullscreen windows look weird when they are overlapped by system chrome,
which currently happens when another window is stacked above. We used to
auto-minimize fullscreen windows in that case, which proved to be both
unreliable and unpopular. So instead, keep the system chrome hidden even
when the fullscreen window is not stacked at the top.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
The constructor would collect windows that are sticky before initializing its state
which would lead to a crash in the case of windows with struts which trigger a work
area recalculation where mutter would assume, due to uninitialized state, that an
existing work area has to be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=738384
There's a small window before a window that is being unmanaged is
unregistered with the display. The MetaScreen::window-left-monitor
and MetaWorkspace::window-removed emissions fall right into that
window, so code that runs in that time may well be out of our
control; we can make sure that the method it can use to get an
updated list of windows no longer contains the destroyed window
though, which is a much better option than expecting everyone to
filter the list themselves.
In Wayland, popup window types are not override-redirect, and thus can
steal window focus away from their parent window when clicked on.
This means that we need to make sure their appearance is properly
propagated to the parent windows so the parent windows don't lose their
focus while they're propagated.
Since we now directly expose the reverses bindings directly, we
don't have to have this special-case in do_choose_window.
More importantly, if the backwards binding is pressed and has the Shift
key included, this will actually revert it
This doesn't matter for Alt-Tab in gnome-shell, which already replaces
it with a better Alt-Tab replacement, but it does matter for Alt-Esc,
which switches between windows directly.
Windows are relocated before their workspace is removed, however this
is only necessary for windows that are *only* on that workspace; for
windows on all workspaces, that step is annoying as it will unset the
sticky state requested by the user.
https://bugzilla.gnome.org/show_bug.cgi?id=737625
The workspace MRU lists are updated when windows are managed/unmanaged
or change workspaces. However those updates obviously only apply to
existing workspaces - new workspaces will always start out with an empty
MRU list, despite sticky windows already being "on" that workspace.
As we now assert that the list contains all windows located on the
workspace, we need to initialize it correctly to avoid a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=737581
We only grant requests to set the demands-attention hint if the window
is at least partially obscured; so for non-minimized windows on the
active workspace, we check if any other window on the same workspace
that is higher in the stack overlaps.
However in the case of a sticky window, window->workspace is NULL, so
we end up considering any non-sticky window on a different workspace.
At this point we have already established that the window is showing
on the active workspace, so use that to filter for windows that may
overlap.
Since the introduction of set_workspace_state(), window->workspace
will always be NULL when on_all_workspaces is set - passing that
to a workspace function that does not validate its input will then
result in a crash.
Use the get_workspace() function instead, which will always return
a valid workspace.
