If a sequence moves past a certain distance without being used by a
gesture, reject it so clients may see and react to it ASAP. This makes
gestures to be began by initially quasi-static touchpoints, in addition to
quasi-simultaneous.
When a passive touch grab is rejected over the frame, management is punted to
the frame itself, and pointer events emulated, but the attempt to transfer the
grab from the GDK connection to the Clutter one fails with AlreadyGrabbed, and
will fail until the Clutter connection receives the XI_TouchEnd resulting from
XIRejectTouch, gotten after the XI_ButtonPress on the GDK connection.
In order to bypass this shortcoming, store the current grab operation on the
frame as long as the button is pressed, so it is retried once on the next
motion event happening during frame dragging, that will have a recent enough
timestamp to succeed. If no grabbing succeeded, the current grab operation
data will be reset on GDK_BUTTON_RELEASE.
When a touch sequence is passively grabbed and later rejected, events
will be replayed on the next client in propagation order, although those
events (either transformed to pointer events or not) will contain the
original timestamps, this will make grabs fail with InvalidTime if triggered
from the replayed ButtonPress/TouchBegin handler.
In order to work around this, store the most recent event time (presumably
gotten from the XI_TouchEnd caused by the passive grab being rejected), and
use that time on the events being replayed afterwards and grabs, so we don't
possibly fail with InvalidTime if those events result in a compositor grab.
Touch events will be caught first by the compositor this way,
whenever the MetaGestureTracker notifies of the accepted/rejected
state of a sequence, XIAllowTouchEvents() will be called on it
accordingly, so it is handled exclusively by the compositor or
punted to clients.
This object tracks both touch sequences happening on the stage and
gestures attached to the stage actor. When a gesture emits
::gesture-begin, All triggering sequences and future ones will be
marked as "accepted" by the compositor, and events will be listened
for meanwhile there are active gestures.
If a sequence goes unclaimed for a short time, it will be
automatically "denied", and punted to the client or shell element
below.
Mutter does its own input event processing, including for the places
where interaction is wanted with the remaining GTK UI elements
(frames), so GDK is largely disposable.
Even though the GDK display connection remains, and events will
be delivered over there due to event selections on that display,
all pointer and touch events will be handled and filtered out by
the GDK filter function.
The dedicated event processing meant for frames in src/ui/ui.c
now hooks to the display connection through
meta_display_events_x11_add_func(), added to let all event filters
run and stop processing at a single point.
Touch events are largely ignored on GdkEvent emulation, so only
make frames receive pointer events, only the pointer emulating
touch will be reported, and any other further touches will be
ignored, which is about the behavior we want. This makes window
dragging possible again on touch.
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.
Since GTK+ already clips to the extended region for us, there's no need
to combine the two. This does lose the fast-path, but I don't actually
expect this to fire, as when we're composited, we really won't ever get
partial exposes.
mutter is quite bad at using GTK+ correctly, relying on dumb things
like the single-buffering stuff. Hack up a temporary fix for the
newer GTK+ rendering changes.
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.
While the comment claims that we may want to keep this around
for optimization purposes, the operations are raw bitmap operations
that would be cleaner done in cairo.
https://bugzilla.gnome.org/show_bug.cgi?id=662962
Struts are defined in terms of screen edges, so expand the rectangles
we get via set_builtin_struts() accordingly. However we do want to
allow chrome on edges between monitors, in which case the expansion
would render an entire monitor unusable - don't expand the rectangles
in that case, which means we will only use them for constraining
windows but ignore them for the client-visible _NET_WORKAREA property.
https://bugzilla.gnome.org/show_bug.cgi?id=730527
Like the _NET_WM_STRUT/_NET_WM_STRUT_PARTIAL client properties,
_NET_WORKAREA is defined in terms of screen geometry rather than
taking individual monitors into account. However we do want to
allow system chrome to be attached to a monitor edge rather than
a screen edges under some circumstances. As not all clients can
be assumed to deal gracefully with the resulting workarea, use
those "struts" only internally for constraining windows, but
ignore them when exporting _NET_WORKAREA.
https://bugzilla.gnome.org/show_bug.cgi?id=730527
Since commit 8b2b65246a, we assume that the compositor always
exists. Alas, the assumption is wrong - the compositor is currently
initialized after the screen, but meta_screen_new() itself may
call a compositor function if initialization involves a workspace
switch (which will happen when meta_workspace_activate() is called
more than once and for different workspaces - or in other words,
when _NET_CURRENT_DESKTOP is set and not 0).
So carefully split out the offending bits and only call them after
the compositor has been initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=731332
If we have a tree of a window, a non-attached dialog, and then an
attached dialog, we want to move the second window, not the attached
dialog or the topmost. In other words, we want to move the first
non-attached window, or the first "freefloating window".
This happens in Firefox, whose Preferences dialog is freefloating,
but suboptions of those are modal dialogs.
There is no way this value will ever be read, because we set the
cursor_surface to NULL, this is set at the same time as cursor_surface,
and it's only read if cursor_surface is non-NULL.
The smallest possible spread corresponds to an unblurred shadow, which
neither grows nor shrinks - thus the spread should be zero not negative
as returned by our current calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=731353
Stupid apps fullscreen themselves by resizing the client window to
monitor size. A monitor-sized frame rect on the other hand is perfectly
normal on monitors without struts - stop force-fullscreening those
and catch the real baddies instead.
https://bugzilla.gnome.org/show_bug.cgi?id=730681
Avoid populating *_VERSION constants through cflags in pkg-config-file
which could be overridden by the project using it. Properly prefix the
defines with META_ to make gi-scanner happy.
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.
The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.
The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.
https://bugzilla.gnome.org/show_bug.cgi?id=724442
There's a race here. If an OR window hides itself, moves, and then shows
itself, we will send a ConfigureNotify for the old size of the window
and might receive it after the client moves itself, causing us to show
the window at the wrong location.
Simply not sending the ConfigureNotify is the easiest thing to do.
Before we unmanage, we send a ConfigureNotify to clients to let them
know if their frame is destroyed. We do this for OR windows too, even if
we really probably shouldn't.
This is based off of the client_rect. Since we listen to ConfigureNotify
on OR windows, we'll receive the event. If we don't ever update the
client_rect when moving or resizing OR windows, then we'll send
ourselves a ConfigureNotify for a 0x0 size and then think that the
client chose a new size for itself. Since our get_paint_volume is based
on that rectangle, but the TFP code inside Cogl uses XGetGeometry
itself, we get weird flickering artifacts.
prelit_control is used for both prelight and pressed states, so the early
return in update_prelit_control() misses the case where prelit_control
already matches the control we are updating, but its state is PRESSED
rather than PRELIGHT. Fix the condition to not have pressed controls
linger around erroneously.
https://bugzilla.gnome.org/show_bug.cgi?id=731058
Since window menus have been moved to the compositor, the pressed
state of the corresponding window buttons is messed up, as it is
reset immediately when getting a LeaveNotify event due to the
compositor taking a grab. Fix this by ignoring that particular
event.
https://bugzilla.gnome.org/show_bug.cgi?id=731058
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.
Smooth scroll event vectors from clutter have the same dimensions as the
ones from from Xi2, i.e. where 1.0 is 1 discrete scroll step. To scale
these to the coordinate space used by wl_pointer.axis
vertical/horizontal scroll events, multiply the vector by 10.
https://bugzilla.gnome.org/show_bug.cgi?id=729601
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.
We have two different coordinate spaces here. One is the rectangle
returned by meta_window_get_frame_rect, which is called the "frame
rect" or "the window geometry", which includes visible frame borders
but not invisible frame borders. The other is "frame->rect" which
corresponds to the frame's server geometry. That is, it includes
both visible and invisible frame borders.
These two were of course the same until we introduced invisible
frame borders, and an executive decision was made to make
meta_window_get_frame_rect return the rectangle bounding the
visible portions of the frame.
As time went on, the "frame rect" turned out to be more useful when
making decisions upon, since the user often doesn't think about the
invisible window geometry as part of the window.
We already calculate what amounts to the "frame rect" in the theme
code, so just change META_CORE_GET_FRAME_RECT to consume that
directly.
Since we're going to be calling meta_window_get_frame_rect in here
soon, I'd rather it be one method call, rather than two. We can't
put it at the toplevel, since that might cause infinite recursion
(e.g. meta_core_get calls meta_window_get_frame_rect calls
meta_ui_get_frame_borders calls meta_core_get, ...)
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
We want to synchronize the button layouts of our server side
decorations and GTK+'s client side ones. However each currently
may contain buttons not supported by the other, which makes this
unnecessarily tricky.
So add support for a new "appmenu" button in the layout, to display
the fallback app menu in the decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
meta_window_get_position() returns the client rect position, which
we then pass to meta_window_move_frame. Just use the existing frame
rect coordinates.
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
We already do it in the theme code, but not the actual WM code. Since
we include the left/right borders, it only seems fair to include the
bottom border.
This effectively makes it so that shading a window means that the
client window "slot" has 0 height.
Otherwise, the X server might read the backend's connection before
GTK+'s, meaning that it sees the XIGrabKeycode requests before the
CreateWindow.
This fixes keybindings on windows not working immediately.
Thanks to Rui Matos <tiagomatos@gmail.com> and
Julien Cristau <jcristau@debian.org> for helping track down the issue.
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
This uses David Herrmann's new logind sessions interface to retrieve
fds for input devices, rather than using a custom setuid helper to do
the management. This vastly simplifies the interface.
This requires systemd v210, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=724604
When switching from the stage cursor to the native cursor, we
forgot to repaint the stage to get rid of the old cursor. Fix
this by having the abstract cursor renderer class track whether
we're using the backend, rather than doing chain-up shenanigans.
The default focus interface uses the button count to determine
whether we should update the pointer focused surface. When releasing
an implicit grab, we need to send the button release events to the
implicitly grabbed surface, so we can't reset the focus surface too
soon. We already explicitly set the focus at the end of implicit
grabs, so counting the buttons after is perfectly fine.
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 expect that meta_screen_set_cursor while grabbed will properly
set the cursor on the root window. Make sure this works by simply
always using the root cursor when we have an active grab.
If we send out a configure notify for a window and then have some
other kind of state change, we need to make sure that we continue
to send out that new size, rather than the last size the client
sent us a buffer for.
In particular, a client might give us a 250x250 buffer and then
immediately request fullscreen. We send out a configure for the
monitor size and a state that tells it it's full-screen, but then
it takes focus, and since the client hasn't sent us a buffer for
the new size, we tell it it's fullscreen at 250x250.
Fix this.
It isn't necessary. As an X11 compositor, we'll only see the event
if we have the grab on the window, anyway.
This was causing issues moving windows as a Wayland compositor.
When we're a Wayland compositor, we get all the events, no exceptions,
so we don't need to grab.
This was masking focusing and raising issues under nested that showed
up under native.
If we apply a prediction immediately instead of queueing, we should
also free the operation immediately.
If we discard the prediction queue because we resync fully, we
need to free each operation too.
https://bugzilla.gnome.org/show_bug.cgi?id=729732
If we exit early as not handled, then the normal process_event
handler will fire, and trigger the overlay-key binding. As that's
a special binding that doesn't have a handler, trying to trigger
that handler will crash mutter.
Instead of returning early, just check for xdisplay every time
we try to drive the X grab state machine. We really need a better
solution for this on the Wayland side.
We can only apply a configuration if its outputs match the connected
ones, so discard the current configuration if the set of output changes
(for example for hotplug), otherwise we will crash trying to apply
the bogus previous configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=725637
If we attach to a MetaWindow that disappears before the idle fires,
we'll notice that we can't associate the window properly again and
try to access data on the MetaWindow struct, which might crash.
Install a weak ref that ties the lifetime of the idle to the lifetime
of the MetaWindow.
It seems every GTK+ app does this for some reason at startup. This
is really unfortunate, since we'll have to create and destroy a new
MetaWindow really quickly.
Scale surfaces based on output scale and the buffer scale set by them.
We pick the scale factor of the monitor there are mostly on.
We only handle native i.e non xwayland / legacy clients yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
Advertise the scale factor on the output and transform pointer and damage
events as well as input and opaque regions for clients
that scale up by themselves i.e use set_buffer_scale.
We do not scale any 'legacy' apps yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
Since commit 6e8d1d79d, move operations are always performed for
the (toplevel) parent of all transient, which is just plain silly
if the dialog is not actually attached to its parent (either because
the dialog is not modal or the setting is disabled).
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.
Ugh. So in the fullscreen case, we need to make sure to specify that
it's a MOVE_ACTION so that we move to the saved position, but we
can't do that in the resizing case since we need to use the resized
rectangle.
The flags are really hurting us here. Perhaps we should make it the
client's responsibility to specify a complete rectangle which we
could resize to; then the weird-o logic would be self-contained in
each front-end.
I'm not convinced this covers all cases, especially when we could have
a dangling weird state pointer, but it fixes our existing two testcases.
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.
Restoring the position in our move_resize_internal implementation
is too late. We need to do it at ack-time, before we hand off the
new position to the constraints code.
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.
For the server-initiated resize case, like unmaximize or some forms
of tiling, we dropped the x/y of the server-assigned rectangle on the
floor, which meant the surface didn't move to where it needed to be in
that case. Now, save it internally, and combine it with the dx/dy passed
in during attaches to figure out where we actually need to be.
Make sure to only use it for when we send out a configure notify. We
should use the passed in rectangle for other scenarios, like a
client-initiated resize.
This fixes incorrect surface placement after unmaximization.
For the server-initiated resize case, like unmaximize or some forms
of tiling, we dropped the x/y of the server-assigned rectangle on the
floor, which meant the surface didn't move to where it needed to be in
that case. Now, save it internally, and combine it with the dx/dy passed
in during attaches to figure out where we actually need to be.
This fixes incorrect surface placement after unmaximization.
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.
Talking it over with Owen, we weren't sure why this was here.
At one point, we were creating a foreign stage window, so potentially
Clutter didn't select for its own events, but now we're using a standard
stage window, so this seems weird.
Why we did it on the COW, nobody knows. Maybe copy/paste bugginess?
Grab operations are now always taken on the backend connection, and
this breaks GTK+'s event handling.
Instead of taking a grab op, just do the handling ourselves. The
GTK+ connection will get an implicit grab, which means pointer /
keyboard events won't be sent to the rest of mutter, which is good.
When we click on a window with a passive grab, then the event_x
and event_y will be relative to that window, instead of relative to
the stage, which means that picking will be wrong.
Forcibly using root_x / root_y breaks nested mode. Nested mode is
a testing mode that should be replaced by a DRI3-enabled Xephyr,
though. It's getting too hairy to support properly.
Now that we grab devices on the X11 connection, we can run into
cross-connection issues. Since GTK+ frames are on the UI connection,
they'll get the passive grab when we click on them. Forcibly ungrab
on GTK+'s connection before attempting to take a grab on the backend
connection ourselves.
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.
Now that we have a global MetaScreen, we can simply have a global
MetaCursorTracker as well. Keep the get_for_screen() API around for
compatibility, though.
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
This doesn't particularly matter, since we fall through into a default
case that does nothing right below, but this matches the other paths
and it prevents us from falling into a trap if we add other event types
below.
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.
Looking at the code paths where is_mouse / is_keyboard are used,
all of them should never be run when dealing with a COMPOSITOR
grab op, since they're filtered out above or the method is just
never run during that time.
It's confusing that COMPOSITOR is in here, and requires us to
be funny with other places in code, so just take it out.
pointer->current needs to always be the surface under the pointer,
even when we have a grab. We do need to make sure we keep the focus
surface the same even when we have a grab, though, so add logic
for that.
In order to correctly fix the issue to make sure we only set the
focused surface to NULL during a grab, but not the current surface,
we need to merge update_current_surface back into repick_for_event
so we have more control over the behavior here.
... not when we do an update.
We only repick when we handle events, not when we update. Perhaps
this is a mistake.
Since update runs before handle_event, this means that when we
drop a grab, update will notice the NULL surface, since we haven't
repicked after the event, and then we'll repick the correct surface.
The end result is that you see a root cursor after a grab ends,
rather than the correct window cursor.
This doesn't fix it, since the current surface becomes NULL when
we start the grab. But it does make the code here more correct when
we fix that bug.
I was talking with other people and they became confused at the
term "double-buffered", since we were also talking about
double-buffering in general, e.g. swapping between two buffers.
Instead, we'll adapt the "pending state" nomenclature that we
already use for the field / variable names.
If we have a focused surface, we need to eat up key events, not
just if we have a non-empty focus resource list. The latter would
happen if we have a focused client but it never called get_keyboard.
The latest Xorg / Xwayland has support for -displayfd being used
in conjunction with an explicit display number. Use that to know
when the X server is ready, rather than UNIX signals, because
they're UNIX signals.
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
Commit 585fdd781c not only removed the tabpopup, but set invalid
handlers (a.k.a. NULL) for those shortcuts; add back handling of
basic handling of those shortcuts by switching instantly without any
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=728423
If we're sending out a configure event, we can't immediately move the
window; we need to instead wait to apply the new position when the
client sends a new buffer.
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.
Sophisticated clients, like those using ClutterGtk, will have more
than one focused resource per client, as both Clutter and GDK will
ask for a wl_pointer / wl_keyboard. Support this naturally using
the same "hack" as Weston: multiple resource lists, where we move
elements from one to the other.
In order to support multiple pointers for the same client, we're
going to need to kill it.
This will cause crashes for now, but will be fixed by the next
commit.
Doing this synchronously means that zenity tries to initialize GTK+.
Under Wayland, that will try to connect back to mutter as a display
server. We're waiting on zenity to exit, and zenity is waiting for
a connection response. Deadlock.
Simply assume that zenity will support all the options we feed it,
since it should be the correct version. Perhaps we should replace
our use of zenity with a simple helper binary that we know will
have all the right options if this still isn't good enough.
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
The code that restacks X11 windows at the end first tracks any
old windows we know about, and then handles any windows created.
It starts when it ended, and then walks forwards and then
back looking for the first X11 window it doesn't know about.
However, when there aren't any X11 windows, it flies off the end
of the array and starts looking through random memory.
When it finds the X11 window, it then goes through and then tries
to restack the remaining windows according to how we've sorted
them.
Unfortunately, META_WINDOW_CLIENT_TYPE_X11 is 0, which is quite
common in random memory we have lying around, so we enter that
path and then just crash.
Fix the buffer overrun by adding the proper bounds check to the
search.
You can easily reproduce this by opening a menu while bloatpad
is full-screen. Why it only crashes when full-screen and not
when a standard window, I have no idea.
default_grab_focus tries to add implicit grab semantics where
focus won't take effect if there's a pointer button down. This
is not what we want for popup grabs at all, as it's perfectly
valid to want to drag on a menu while there's a button down.
The idea here is that while we take a WM-side grab, like a compositor
grab or a resizing grab, we need to remove the focus from the Wayland
client.
We make a special exception for CLICKING operations, because these
are really an internal state machine while you're pressing on a button
inside a frame, and in this case, we need to not kill the focus.
Really, it is a special case. When the subsurface is synchronous,
commit changes meaning from being applied immediately to being
queued up for replay later. Handle this explicit special case
with an explicit special case in the code.
This means that in all other paths, we can unconditionally
apply the actor immediately.
Even when it doesn't have a role.
This fixes cursors not quite working right, as they're a "detached"
surface without a role since nobody called set_cursor on them yet.
Instead of using commit_attached_buffer / actor_surface_commit.
We want to kill the return values of these methods because we
really should always be calling them, even if the surface doesn't
have a role.
This is also something that we did upstream. Since we want to
introduce an explicit "xdg_transient" window type for tooltips
and popovers, and since "transient_for" is a confusing dumb
80s term lifted from the ICCCM spec, just rename it.
This was changed upstream a little while ago for C++ compatibility.
It's also the more common term for the operation: you close a window,
you don't delete one. In fact, a delete event might seem like it
would be about resource management instead.
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
This has one regression: the basic touch support added by
Carlos Garnacho in 991c85f is now partially reverted, since
we ported to Clutter events for this. We'll need to either
port his changes to Clutter, or restructure event handling
in mutter directly.
We can't really support the Gtk+ automatic scaling, as to much
code relies on the GdkWindow and XWindow sizes, etc to match.
In order to keep working we just disable the scaling, meaning
we will pick up the larger fonts, but nothing else. Its not
ideal but it works for now.
https://bugzilla.gnome.org/show_bug.cgi?id=706388
Due to changes in gnome-common git, an implicit m4 directory is no
longer created during autogen. The attached patch explicitly and
correctly specifies a macro directory.
https://bugzilla.gnome.org/show_bug.cgi?id=706787
When _GTK_FRAME_EXTENTS changes, we need to redo constraints on
the window - this matters in particular if the toolkit removes
invisible borders when a window is maximized, since otherwise
the maximized window will be positioned as if it still has
invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
A gulong is not enough to get 64 bits in all arches, so we must
cast it, or we can corrupt the stack.
This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055
https://bugzilla.gnome.org/show_bug.cgi?id=707267
Apparently some connector technologies don't distinguish between
on and off, and there might be valid use cases for running without
any connected monitor.
In that case, just avoid any configuration at all.
https://bugzilla.gnome.org/show_bug.cgi?id=709009
Each level in the tower is initialized by binding the texture for that
level to an offscreen framebuffer and rendering the previous level as a
textured rectangle. The problem was that we were blending the previous
level with undefined data so argb32 windows with transparencies would
result in artefacts. This makes sure to disable blending when drawing
the textured rectangle.
After reading the atom, scale the value from 0xffffffff to 0xff. Not doing so
causes Clutter to truncate the opacity value, and only read the last two digits.
Hence, 0x7fffffff (50%) becomes 0xff (100%).
https://bugzilla.gnome.org/show_bug.cgi?id=727874
After reading the atom, scale the value from 0xffffffff to 0xff. Not doing so
causes Clutter to truncate the opacity value, and only read the last two digits.
Hence, 0x7fffffff (50%) becomes 0xff (100%).
https://bugzilla.gnome.org/show_bug.cgi?id=727874
A careful analysis of mutter's codebase shows that nothing actually
passes anything but 0 to this. gnome-shell has one instance, but it's
most likely a mistake.
Remove the grab_mask field and the one place in keybindings.c that uses it.
The parameter to begin_grab_op is left in for API compatibility reasons.
Since we get the ClientMessage after the surface is created, there's
no good way to synchronize the two streams. In this case, what we
need to do is delay the surface commit until after we get the
ClientMessage. Ideally, we'd be using a better surface system overall
where committing the surface didn't depend on what type it is, but
oh well, this is a good short-term hack for now.
This is effectively the same, but since we lose the xserver.xml protocol
in the new XWayland DDX, we have to use SIGUSR1 anyway, so might as well
switch over now.
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.
It should be META_TYPE_WAYLAND_STAGE, not META_WAYLAND_TYPE_STAGE.
Well, actually, it *should* be META_TYPE_NATIVE_STAGE, because it's
not related to Wayland at all. But that comes later :)
Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.
This will allow us to have a MetaCursorReference 'subclass' that's
lazily loaded. We currently always load all the images.
The long-term plan is to have a subclass for each "backend" and only
have CoglTexture as a common denominator. For the nested X11 backend,
we use XDefineCursor on our stage window. For the Wayland backend, we
would use set_cursor on our stage surface. For the native backend, we
would use the GBM code that's there right now.
The CoglTexture is there to be a "shared fallback" between all devices,
and also for the get_sprite API.
The odd man out is the X11 compositor case. For that, we need to move
the responsibility of setting the final cursor image out of
MetaCursorTracker, and simply have it be about tracking the used sprite
image and pointer position.
We want to make this private, and have MetaCursorReference be
backend-defined, with the texture possibly loaded on demand.
We can't make the definition of MetaCursorReference truly private yet
because of the XFixes cursor. A victim of MetaCursorTracker trying to
do too many things at once...
I want the MetaCursorTracker to mostly be about retrieving cursor
information. Start moving the code that loads cursor images to a
new file, MetaCursor. Eventually, MetaCursorTracker's APIs will
all take MetaCursorReferences, and we can have a clean backend
split here.
For whatever reason, this hash table was in the generic
implementation section instead of the XSync implementation,
even though it's only used by the XSync implementation.
Use it as a first pass of things to move over.
The reason we don't simply use gdk_window_add_filter directly is
because of some twisted idea that any GDK symbol being used from
core/ is a layer violation. While we certainly want to keep any
serious GDK code out of ui/, event handling is quite important
to have in core/, so simply use a GDK event filter directly.
The code here before was completely wrong. Not only did it mix up
coordinate spaces of "client rect" vs. "frame rect", but it used
meta_frame_get_frame_bounds, which is specifically for the *visible*
bounds of a window!
In the case that we don't have a bounding or input shape region at
all on the client window, the input shape that we should apply is
the surface's natural shape. So, set the region to NULL to get the
natural rect picking semantics.
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 guarantee ourselves that a valid pixmap will appear any time
that the window is painted. The window actor will be scheduled
for a repaint if it's added / removed from the scene graph, like
during construction, if the size changes, or if we receive damage,
which are the existing use cases where this function is called.
So, I can't see any reason that we queue a redraw in here.
With the split into surface actors, we don't have an easy place
we can use to queue a redraw, and since it's unnecessary, we can
just drop it on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.
We still keep MetaScreen in the public compositor API for compatibility
purposes.
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.
I'm a bit tired of hearing about this when I launch mutter-wayland
nested. Ideally, this would be part of display server integration,
not GNOME integration, so we could simply not make the call when
nested, but oh well.
cogl_texture_get_components can be used on both X11 and Wayland
backends. Technically, the detection is different: we actually
check the actual RENDER format in the old code, while Cogl simply
assumes that any pixmap with a depth >= 32 is ARGB32. Since Cogl
already seems to be working with its internal checks, it makes
more sense to use Cogl's check rather than keeping our own.
is_argb32 can be called at any time, including times when we don't
have a texture. In that case, just assume we're ARGB32. The value
really shouldn't be important though.
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.
display.c is getting a bit crowded. Move most of the handling
out to another file, events.c.
The long-term goal is to have generic event handling here, with
backend-specific handling for the types of windows and such.
Previously, a sequence like this would crash a client:
=> surface.attach(buffer)
=> buffer.destroy()
The correct behavior is to wait until we release the buffer before
destroying it.
=> surface.attach(buffer)
=> surface.attach(buffer2)
<= buffer.release()
=> buffer.destroy()
The protocol upstream says that "the surface contents are undefined"
in a case like this. Personally, I think that this is broken behavior
and no client should ever do it, so I explicitly killed any client
that tried to do this.
But unfortunately, as we're all well aware, XWayland does this.
Rather than wait for XWayland to be fixed, let's just allow this.
Technically, since we always copy SHM buffers into GL textures, we
could release the buffer as soon as the Cogl texture is made.
Since we do this copy, the semantics we apply are that the texture is
"frozen" in time until another newer buffer is attached. For simple
clients that simply abort on exit and don't wait for the buffer event
anyhow, this has the added bonus that we'll get nice destroy animations.
If we have a CLICKING grab op we still need to send events to xwayland
so that we get them back for gtk+ to process thus we can't steer
wayland input focus away from it.
https://bugzilla.gnome.org/show_bug.cgi?id=726123
meta_wayland_seat_repick() can be called in various cases while mutter
has a GRAB_OP ongoing which means we could be sending wrong pointer
enter/leave events.
https://bugzilla.gnome.org/show_bug.cgi?id=726123
This ensures that we send the proper leave and enter events to wayland
clients.
Particularly, this solves a bug in SSD xwayland windows where clicking
and dragging on the title bar to move the window only works on the odd
turn (unless the pointer moves away from the title bar between
tries). This happens because xwayland gets a button press but doesn't
see the release so when it gets the next button press it discards it
because its pointer button tracking logic says that the button is
already pressed. Sending the proper wayland pointer leave event fixes
it since wayland clients must forget about button state at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=726123
At one point, it was supported to run mutter without a compositor,
but we don't allow that any longer. A lot of code already assumes
display->compositor exists and doesn't check for a NULL pointer,
so just kill the rest of the checks.
This is specifically about managing X11 windows, not necessarily
running as an X11 compositor. By that I mean that this code is
still used for XWayland windows, and event handling is still and
modesetting / monitor management is still in core/.
This is also a fairly conservative move. We don't move anything
like screen.c or bell.c in here, even though those are really
only for X11 clients.
This is fairly simple and basic for now, with just skip_taskbar /
skip_pager, but eventually a lot of "WM policy" like this, including
move-resize, will be in subclasses for each individual surface.
In particular we need to know about all key events to keep the xkb
state reliable even if the event is then consumed by a global shortcut
or grab and never reaches any wayland client.
We also need to keep track of all pressed keys at all times so that we
can send an updated set or pressed keys to the focused client when a
grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
Any given clutter event carries the modifier state as it was before it
occured but, for the wayland modifiers event, we want the state
including the current event.
To fix this, we'll keep our xkb_state instance around instead of the
serialized mods.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
This reverts commit f0c503b5a9.
01:08 < Jasper> desrt, can you revert that mutter-wayland commit for me?
My laptop with git on it is out of commission.
Currently touch events are ignored in the core event handler,
and hence dealt with within GDK. If those touch events were
emulating pointer events, GDK would attempt to convert back
those events to pointer events as the frame GdkWindow doesn't
have the GDK_TOUCH_MASK set.
This results in XI_TouchBegin events being initially processed
by GDK, converted to button events, and triggering a grab op
that subverts touch events into pointer events, so the touch
is never ever seen again by GDK. This leaves GDK in an
inconsistent internal state wrt pointer grabs, so future
pointer-emulating touches will refer to the same window forever.
Fix this by handling touch events minimally, just enough to
convert XI_TouchBegin to GDK_BUTTON_PRESS within mutter, so GDK
is bypassed for every touch event just like it is for pointer
events. This, and the XIGrabDevice() that keeps coercing pointer
events when the grab operation starts, are enough to fix window
drag and drop on touch devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723552
We try to exempt CSD windows from being forced fullscreen if they are
undecorated and the size of the screen; however, we also catch almost
all windows that *do* need to be forced fullscreen in this check, since
they also have decorations turned off.
Identify actual CSD windows by checking whether _GTK_FRAME_EXTENTS is set -
GTK+ will always set this on CSD windows even if they have no invisible
borders or shadows at the current time.
We explicitly turn off the legacy-fullscreen check for native wayland windows
so we don't start legacy-fullscreening them if the new
meta_window_is_client_decorated() is later made more accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=723029
We try to exempt CSD windows from being forced fullscreen if they are
undecorated and the size of the screen; however, we also catch almost
all windows that *do* need to be forced fullscreen in this check, since
they also have decorations turned off.
Identify actual CSD windows by checking whether _GTK_FRAME_EXTENTS is set -
GTK+ will always set this on CSD windows even if they have no invisible
borders or shadows at the current time.
https://bugzilla.gnome.org/show_bug.cgi?id=723029
The user_rect represents the unconstrainted window size, and lots
of code in mutter assumes it can resize to the user_rect at any
time. If we wait for an attach to ACK and save the user rect, we'll
see lots of flickering as code is resizing to the old user_rect
at any time.
Make it a compile-time flag rather than a run-time flag, because
practically any time you're going to be debugging event spewing,
you're going to have to recompile anyway. Remove the WITH_VERBOSE_MODE
checks, too.
Which is used for Wayland popup grabs.
The issue here is that we don't want the code that raises or focuses
windows based on mouse ops to run while a client has a grab.
We still keep the "old" grab infrastructure in place for now, but
ideally we'd replace it eventually with a better grab-op infrastructure.
Clutter's input device initial position defaults to (-1, -1) on most
backends but for the evdev backend we changed it to be inside the
stage to prevent the pointer from wandering outside the stage until it
first enters, after which our constraining callback won't let it go
out.
This makes us be in sync with the real position from the start.
_SVID_SOURCE has been deprecated in newer versions of glibc breaking
-WError; the recommended replacement of _DEFAULT_SOURCE is fairly
new, so switch to _XOPEN_SOURCE instead.
_SVID_SOURCE has been deprecated in newer versions of glibc breaking
-WError; the recommended replacement of _DEFAULT_SOURCE is fairly
new, so switch to _XOPEN_SOURCE instead.
The "original coordinates" passed into meta_window_place() were the
coordinates of the client rectangle not the frame rectangle. When
meta_window_place() didn't place because the window was manually
positioned (e.g., 'xterm -geometry +x+y') that resulted in a window
being offset by the frame dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=724049
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
The "original coordinates" passed into meta_window_place() were the
coordinates of the client rectangle not the frame rectangle. When
meta_window_place() didn't place because the window was manually
positioned (e.g., 'xterm -geometry +x+y') that resulted in a window
being offset by the frame dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=724049
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Creating a new cogl texture may fail, in which case the intent to
free it will crash. While something is clearly wrong (insanely
large window, oom, ...), crashing the WM is harsh and we should
try to avoid it if at all possible, so carry on.
https://bugzilla.gnome.org/show_bug.cgi?id=722266
Do to a bad mixup, the surface listener was never actually fired.
This was accidentally fixed as part of a refactoring in a27fb19,
but the surface listener was broken, and we started crashing. To
fix, just remove the surface listener, as we've mostly been testing
without it.
This is not needed since the instance is being destroyed and in fact
actively harmful when code called from other handlers disconnects us
for other reasons. In that case we might crash because the
disconnection doesn't prevent other handlers from running in the
current signal emission and thus we try to remove ourselves from an
empty list.
Creating a new cogl texture may fail, in which case the intent to
free it will crash. While something is clearly wrong (insanely
large window, oom, ...), crashing the WM is harsh and we should
try to avoid it if at all possible, so carry on.
https://bugzilla.gnome.org/show_bug.cgi?id=722266
This changes the user data of all surface extensions resources to be
the MetaWaylandSurface instead of the MetaWaylandSurfaceExtension,
which means that we no longer need all these pesky wl_container_ofs
in implementations.
Don't set the surface actor to a new buffer if it's becoming unmapped.
This is also technically wrong since we'll send out the release event,
but oh well.
We should probably decouple MetaWaylandBuffer from the CoglTexture
at some point, so we can send out releases on-demand.
We don't want to match the keysym so that e.g. an accelerator
specified as "<Super>a" works if the current keymap has a keysym other
than 'a' for that keycode which means that the accelerator would
become inaccessible in a non-latin keymap.
This is inconvenient for users that often switch keyboard layouts, or
even have different layouts in different windows, since they expect
system-level keybindings to not be affected by the current layout.
https://bugzilla.gnome.org/show_bug.cgi?id=678001
We don't want to match the keysym so that e.g. an accelerator
specified as "<Super>a" works if the current keymap has a keysym other
than 'a' for that keycode which means that the accelerator would
become inaccessible in a non-latin keymap.
This is inconvenient for users that often switch keyboard layouts, or
even have different layouts in different windows, since they expect
system-level keybindings to not be affected by the current layout.
https://bugzilla.gnome.org/show_bug.cgi?id=678001
The only events we handle as XIEvents are FocusIn/Out, Enter and
Leave. Motion, ButtonPress/Release, KeyPress/Release are handled
through clutter instead.
Among other things, this means we don't need to fake motion compression
by peeking over gdk event queue...
All WM events (passive button grabs and passive keyboard grabs)
are handled through clutter now, so we must make sure we spoof
them even if they happen on frames (because that's where we
grab on)
Weirdly, clutter stopped segfaulting when we call clutter_x11 methods
and the backend is not right, but this is correct anyway, and
probably fixes some BadDrawable errors in mutter-wayland on x11,
caused by mixing windows of the outer X and windows of Xwayland.
Mouse event handling was duplicated, resulting in weird interactions
if clutter was allowed to see certain events (for example under
wayland, where it gets all events). Because now clutter sees all
X events, even when running as an x11 compositor, we can handle
everything using the clutter variants.
At the same time, rewrite a little the passive button grab code,
to make it clear what is being matched on what and why.
meta_ui_window_is_widget() returns FALSE for frame windows, so we
must filter those explicitly (by letting the event go to gtk
and from there to MetaFrames). Also, for proper gtk widgets
(window menus) we want to let gtk see all events, including
keyboard, otherwise we break keynav in the window menu.
This means that having a window menu open disables keybindings
(because the event doesn't run through clutter)
We must spoof events to clutter even if they are associated
with a MetaWindow, because keyboard events are always associated
with one (the focus window), and we must process keybindings
for window togheter with the global ones if they include Super,
because we're not going to see them again.
... and individually. It turns out that updating the opaque region
was causing the shape region to be updated, which was causing a new
shape mask to be generated and uploaded to the GPU. Considering
GTK+ regenerates the opaque region on pretty much any focus change,
this is not good.
For decorated windows, we don't want to apply any input
shape, because the frame is always rectangular and eats
all the input.
The real check is in meta-window-actor, where we consider
if we need to apply the bounding shape and the input shape
(or the intersection of the two) to the surface-actor,
but as an optimization we avoid querying the server in
meta-window.
Additionally, for undecorated windows, the "has input shape"
check is wrong if the window has a bounding shape but not an
input shape.
... and individually. It turns out that updating the opaque region
was causing the shape region to be updated, which was causing a new
shape mask to be generated and uploaded to the GPU. Considering
GTK+ regenerates the opaque region on pretty much any focus change,
this is not good.
The handler pointer is dangling in MetaKeyBinding until
rebuild_key_binding_table() is run, so we can't dereference it.
Because we only need the flags at ungrab time, store a copy
in the MetaKeyBinding structure.
https://bugzilla.gnome.org/show_bug.cgi?id=724402
The handler pointer is dangling in MetaKeyBinding until
rebuild_key_binding_table() is run, so we can't dereference it.
Because we only need the flags at ungrab time, store a copy
in the MetaKeyBinding structure.
https://bugzilla.gnome.org/show_bug.cgi?id=724402
At some point meta_window_actor_cull_out stopped calling
meta_cullable_cull_out_children which caused the unobscured region
to never be set for the stex.
https://bugzilla.gnome.org/show_bug.cgi?id=725216
For decorated windows, we don't want to apply any input
shape, because the frame is always rectangular and eats
all the input.
The real check is in meta-window-actor, where we consider
if we need to apply the bounding shape and the input shape
(or the intersection of the two) to the surface-actor,
but as an optimization we avoid querying the server in
meta-window.
Additionally, for undecorated windows, the "has input shape"
check is wrong if the window has a bounding shape but not an
input shape.
We need a MetaWaylandSurface to build a MetaSurfaceActor, but
we don't have one until we get the set_window_xid() call from
XWayland. On the other hand, plugins expect to see the window
actor right from when the window is created, so we need this
empty state.
Based on a patch by Jasper St. Pierre.
Turns out we only ever need to freeze/thaw whole windows, not
surfaces or subsurfaces.
This will allow removing the surface actor without losing
the count.
This time, to make way for MetaSurfaceActorEmpty. This also fixes
destroy effects as a side effect. It still has issues if we try
to re-assign an actor that's already toplevel (e.g. somebody
re-popping up a menu that's already being destroyed), but this
will be fixed soon.
The idea here is that MetaWindowActor will do the unparenting of
the surface actor when it itself is destroyed. To prevent bad issues
with picking, we only make the surface actor reactive when it's
toplevel.
It triggers too often, making G_DEBUG=fatal-warnings quite useless.
Owen is going to rewrite this code sometime in the near future, so
I'm just gonna kill this warning for now.
If the last reference of a MetaIdleMonitor is held by the caller, it may
happen that the last reference is lost when calling the GDestroyNotify,
if this happens when the watched DBus name vanishes, the object (and the
watches hashtable) are destroyed while manipulating the watches hashtable,
so bad things may happen then.
Fix this by wrapping the operation by a ref/unref pair, so the object would
be destroyed after operating on the hashtable.
https://bugzilla.gnome.org/show_bug.cgi?id=724969
gnome-shell has some complex tracking to set the X input focus
correctly, assuming various things about how the stage is set up in X11.
For instance, it assumes that all actors that get key focus are
gnome-shell Chrome actors that will get events through the stage, so
when one of them is focused, it will try to set the focus back to the
stage.
In Wayland, windows are considered chrome actors that will get key
events through the stage, so this only has the result of unfocusing any
windows that have just received key focus.
We should probably move this input focus moving to mutter instead of
gnome-shell so we can better use mutter's internal state and heuristics.
If the last reference of a MetaIdleMonitor is held by the caller, it may
happen that the last reference is lost when calling the GDestroyNotify,
if this happens when the watched DBus name vanishes, the object (and the
watches hashtable) are destroyed while manipulating the watches hashtable,
so bad things may happen then.
Fix this by wrapping the operation by a ref/unref pair, so the object would
be destroyed after operating on the hashtable.
https://bugzilla.gnome.org/show_bug.cgi?id=724969
We cannot intersect the the complete volume with the unobscured bounds
because it does not include the shadows. So just intersect it with the
windows's shape bounds and union it with the shadow bounds.
This also matches what the comment in the code says:
"We could compute an full clip region as we do for the window texture,
but the shadow is relatively cheap to draw, and a little more complex to clip,
so we just catch the case where the shadow is completely obscured
and doesn't need to be drawn at all."
We cannot intersect the the complete volume with the unobscured bounds
because it does not include the shadows. So just intersect it with the
windows's shape bounds and union it with the shadow bounds.
This also matches what the comment in the code says:
"We could compute an full clip region as we do for the window texture,
but the shadow is relatively cheap to draw, and a little more complex to clip,
so we just catch the case where the shadow is completely obscured
and doesn't need to be drawn at all."
It turns out XKB has keysyms for these for no real reason, and I
was hitting those instead of the <Primary><Alt>F1 path. This is
ridiculous, but key, so is the entirety of XKB.
This took an embarassingly long time to figure out and debug.
The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:
* X11 compositor. In this case, we're a traditional X11 compositor,
not a Wayland compositor. We use XCompositeNameWindowPixmap to get
the backing pixmap for the window, and deal with the COMPOSITE
extension messiness.
In this case, meta_is_wayland_compositor() is FALSE.
* Wayland clients. In this case, we're a Wayland compositor managing
Wayland surfaces. The rendering for this is fairly straightforward,
as Cogl handles most of the complexity with EGL and SHM buffers...
Wayland clients give us the input and opaque regions through
wl_surface.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.
* XWayland clients. In this case, we're a Wayland compositor, like
above, and XWayland hands us Wayland surfaces. XWayland handles
the COMPOSITE extension messiness for us, and hands us a buffer
like any other Wayland client. We have to fetch the input and
opaque regions from the X11 window ourselves.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.
We now split the rendering logic into two subclasses, which are:
* MetaSurfaceActorX11, which handles the X11 compositor case, in that
it uses XCompositeNameWindowPixmap to get the backing pixmap, and
deal with all the COMPOSITE extension messiness.
* MetaSurfaceActorWayland, which handles the Wayland compositor case
for both native Wayland clients and XWayland clients. XWayland handles
COMPOSITE for us, and handles pushing a surface over through the
xf86-video-wayland DDX.
Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
It's mostly equivalent to the case where we've already detached
the pixmap, *except* for the x11_size_changed case. We can simply
detach the pixmap at the time the window changes size, though.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We guarantee ourselves that a valid pixmap will appear any time
that the window is painted. The window actor will be scheduled
for a repaint if it's added / removed from the scene graph, like
during construction, if the size changes, or if we receive damage,
which are the existing use cases where this function is called.
So, I can't see any reason that we queue a redraw in here.
With the split into surface actors, we don't have an easy place
we can use to queue a redraw, and since it's unnecessary, we can
just drop it on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
If the client destroys the pointer resource, we shouldn't unfocus the
surface, and we should regrab it when the client gets the pointer
resource again.
This also fixes a crash at surface destruction because of the unchecked
wl_link_remove that will happen on both pointer and surface destroy.
We can never have a window actor that represents either the X root
window or the stage window, so it doesn't make sense to bail out
early in case we do.
I'd imagine that this came from a much earlier version of the code
where the compositor was much separate and had its own MapNotify
handling.
This reverts commit 283a81eac0.
This can't be done yet, as it will crash when we try to do a destroy
effect from a plugin. The surface actor needs to outlive the surface
in this case.
Though, the unparenting happening is wrong anyway for a destroy effect.
We need to figure out a sane way of doing this unparenting only after
all effects have finished.
As resource destruction can happen in any order at shutdown, we
need to be flexible here. A client disconnecting without cleaning
up all its resources should not assert fail.
Since the unredirected window MetaWindowActor is stacked on top, it
will naturally get culled out of the process, so we can remove the
special casing here. Unfortunately, with the way that the code is
currently structured, it's too difficult to actually prevent setting
the clip / visible regions if the window is redirected, so just let
those be set for unredirected windows for now.
The input region was set on the shaped texture, but the shaped texture
was never picked properly, as it was never set to be reactive. Move the
pick implementation and reactivity to the MetaSurfaceActor, and update
the code everywhere else to expect a MetaSurfaceActor.
I implemented pinging, but never actually enabled the feature
properly on Wayland surfaces by setting the net_wm_ping hint to
TRUE, causing the fallback path to always be hit.
Rename net_wm_ping to can_ping so it doesn't take on an
implementation-specific meaning, and set it for all Wayland windows.
I tested this with meta_window_get_input_rect and decided to change
it at the last minute. Turns out meta_window_get_rect is unlike all
the others. Just access window->rect directly instead.
Now that we call set_custom_frame_extents, the frame rect corresponds
to the "visible window geometry" used for constrainment, while the
x/y fields in get_xdg_popup instead are relative to the surface.
Something noticed on code inspection. If we have a popup grab,
it will always return FALSE. The code here clearly meant to continue
if we had an existing popup grab from an existing client.
Both the pointer/keyboard resource and surface resource can be destroyed
at any point in the destruction process, so we need to have destroy
listeners on both. To make the code easier to follow, rename ->focus
to ->focus_surface at the same time, and rearrange the code so that
the two of them are always grouped together.
To prevent the MetaSurfaceActor from being destroyed, we normally
unparent it before we unmanage the window. However, this doesn't
work for XWayland windows, which we unmanage when we get UnmapNotify
or DestroyNotify, not when we get the wl_surface_destroy.
To solve this, add an early hook in meta_window_unmanage that
unparents the surface actor if we have one. At the same time, clean
up the destruction code to remove old comments and assumptions about
how wl_shell behaves.
It doesn't work now that we set the pivot point. This breaks the
maximize effect, but it fixes the destroy effect. The maximize effect
looks bad anyway, so it's not too important to me.
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Conflicts:
src/compositor/compositor.c
src/meta/util.h
This was a bad idea, as ping/pong has moved to a client-specific
request/event pair, rather than a surface-specific one. Revert
the changes we made here and correct the code to make up for it.
This reverts commit aa3643cdde.
If we fail to find the IDLETIME counter, then the alarm variable will be
uninitialised. Most code paths are careful to check this before
submitting XSync calls, but there is one check missing.
https://bugzilla.gnome.org/show_bug.cgi?id=724364
In order for the compositor to properly determine whether a client
is an X11 client or not, we need to wait until XWayland calls
set_window_id to mark the surface as an XWayland client. To prevent
the compositor from getting tripped up over this, make sure that
the window has been fully initialized by the time we call
meta_compositor_add_window.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
In order for the compositor to properly determine whether a client
is an X11 client or not, we need to wait until XWayland calls
set_window_id to mark the surface as an XWayland client. To prevent
the compositor from getting tripped up over this, make sure that
the window has been fully initialized by the time we call
meta_compositor_add_window.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.
However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.
I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.
Remove this now.
The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.
At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.
However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.
I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.
Remove this now.
The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.
At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
If we fail to find the IDLETIME counter, then the alarm variable will be
uninitialised. Most code paths are careful to check this before
submitting XSync calls, but there is one check missing.
https://bugzilla.gnome.org/show_bug.cgi?id=724364
Prior to the DisplayConfig merge, we would set _NET_WM_FULLSCREEN_MONITORS
to (unsigned)-1 when unset. After that, we would have invalid
reads inside meta_screen_monitor_index_to_xinerama_index() (called
with -1).
The way I read the specification, the proper way to indicate
that the window is back to fullscreen on all monitors is to
remove the property, so do that.
Also, add an assertion that meta_screne_monitor_index_to_xinerama_index()
is doing the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=724258
Prior to the DisplayConfig merge, we would set _NET_WM_FULLSCREEN_MONITORS
to (unsigned)-1 when unset. After that, we would have invalid
reads inside meta_screen_monitor_index_to_xinerama_index() (called
with -1).
The way I read the specification, the proper way to indicate
that the window is back to fullscreen on all monitors is to
remove the property, so do that.
Also, add an assertion that meta_screne_monitor_index_to_xinerama_index()
is doing the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=724258
We want to remove a bunch of auxilliary duties from the MetaWindowActor
and MetaSurfaceActor, including some details of how culling is done.
Move the unobscured region culling code to the MetaShapedTexture, which
helps the actor become "more independent".
https://bugzilla.gnome.org/show_bug.cgi?id=720631
When we traversed down to reset the culling state, previously we
would just skip any actors that wanted culling. In order to properly
reset the unobscured_region before painting, we need to traverse down
to these places as well. Do this by calling cull_out with NULL regions
for both arguments, and adapt existing cull_out implementations to
match.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We want to remove a bunch of auxilliary duties from the MetaWindowActor
and MetaSurfaceActor, including some details of how culling is done.
Move the unobscured region culling code to the MetaShapedTexture, which
helps the actor become "more independent".
https://bugzilla.gnome.org/show_bug.cgi?id=720631
When we traversed down to reset the culling state, previously we
would just skip any actors that wanted culling. In order to properly
reset the unobscured_region before painting, we need to traverse down
to these places as well. Do this by calling cull_out with NULL regions
for both arguments, and adapt existing cull_out implementations to
match.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
It seems that this code is trying to transform from "surface coordinates"
(the size of texture that's being displayed) to "actor coordinates"
(the actor's allocation), but I can't find any place where the two are
different. As such, let's just go back to using "surface coordinates"
everywhere and see what breaks.
This is considered "undefined" by upstream. Right now GTK+ does this
a lot, so we shouldn't crash. Let's make them crash instead and send
them an error instead.
The code that prevents the creation of multiple MonitorInfos for clones
wasn't working due to using the wrong index when getting the already
created info so fix that to use the correct one.
https://bugzilla.gnome.org/show_bug.cgi?id=710610
The code that prevents the creation of multiple MonitorInfos for clones
wasn't working due to using the wrong index when getting the already
created info so fix that to use the correct one.
https://bugzilla.gnome.org/show_bug.cgi?id=710610
Use our new "surface_mapped" field to delay the showing of XWayland clients
until we have associated together the window's XID and the Wayland surface ID.
This ensures that when we show this window to the compositor, it will properly
use the Wayland surface for rendering, rather than trying to use COMPOSITE and
crash.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
The goal here is to make MetaWindow represent a toplevel, managed window,
regardless of if it's X11 or Wayland, and build an abstraction layer up.
Right now, most of the X11 code is in core/ and the wayland code in wayland/,
but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
Moving the mouse over weston-terminal, we can see several issues:
* it often updates late, or not at all
* the attachment of the pointer sprite is wrong
These are because we willy-nilly call seat_update_sprite all over the
place, and often in wrong areas. Set up a set_pointer_surface helper
method that will do the right thing for us in all cases, and call it
on transitions.
Currently, set_cursor isn't properly working. Often, the requests look
like this:
cursor_surface = wl_compositor.create_surface()
cursor_buffer = create_cursor_buffer()
cursor_surface.attach(cursor_buffer, 0, 0)
cursor_surface.commit()
wl_pointer.set_cursor(cursor_surface, 7, 14)
But since the surface doesn't "have a role" when the commit comes in,
we ignore it, and don't do anything with the pending buffer. When
set_cursor is called, however, we don't immediately update anything
since it doesn't have a buffer.
This effectively means that set_cursor has unpredictable side effects.
Weston's toy toolkit reuses the same surface for every buffer, so it
only fails the first time. In clients that use a new surface for every
cursor sprite, the cursor is effectively invisible.
To solve this, change the code to always set the buffer for a surface,
even if it doesn't have any real role.
Refactor our commit() implementation out of wl_surface_commit(),
and pass the double-buffered state around to all our implementation
methods. This allows us to drop a few lines destroying and
reinitializing list of frame callbacks. This is a big cleanup for
the next commit, though.
X11 window frames use special UI grab ops, like META_GRAB_OP_CLICKING_MAXIMIZE,
in order to work properly. As the frames in this case are X11 clients, we need
to pass through X events in this case. So, similar to how handle_xevent works,
use two variables, bypass_clutter, and bypass_wayland, and set them when we
handle specific events.
To prevent corruption, our focus listener needs to be removed even when
the surface is destroyed. So, bailing out when pointer->focus->resource
is NULL just isn't good enough.
Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Using a full InputOutput window causes us to make a full Wayland surface
for it, and go through the X server. As the goal of the guard window is
a window for us to stack minimized windows under so we can prevent them
from getting input, it makes sense to use an InputOnly window here.
Using a full InputOutput window causes us to make a full Wayland surface
for it, and go through the X server. As the goal of the guard window is
a window for us to stack minimized windows under so we can prevent them
from getting input, it makes sense to use an InputOnly window here.
We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=721596
We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=721596
Implement support for synchronous subsurfaces commits. This means that
the client can, by calling wl_subsurface.set_sync, cause its surface
state to be commited not until its parent commits.
This will mean there will be will potentially be one more surface state
(regions, buffer) at the same time: the active surface state, the mutable
pending surface state, and the immutable surface state that was pending
on last surface commit.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
We need to do this for XWayland windows, since we only get the event
telling us they're an XWayland window after the compositor knows about
the window.
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
We no longer unmap the toplevel windows during normal operation. The
toplevel state is tied to the window's lifetime.
Call meta_compositor_add_window / meta_compositor_remove_window instead...
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.
However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.
I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.
Remove this now.
The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. Theoretically, we might want to
show previews of shaded windows in the overview and Alt-Tab, so we remove
the complex unmap tracking for this later.
This reverts commit ebe6e3180e.
This is wrong, as mutter's controlling TTY may not be the same
as the active VT, and in fact won't be in the case of systemd
spawning us.
The "correct" API for this is to use David Herrmann's
"Session Positions" system to switch to another VT:
http://lists.freedesktop.org/archives/systemd-devel/2013-December/014956.html
For x defined below, x == -INT32_MAX assuming that the arithmetic
expression actually uses the fpu.
float f = 1.0f;
int32_t x = INT32_MAX * f;
This would result in the calculated clip width/height to be -INT_MAX
if the damage width/height is INT_MAX. To solve this, use a double
variable instead.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
Make MetaWindowActor chain up to the generic default MetaCullable
implementation, and remove the helper methods for MetaSurfaceActor
and MetaShapedTexture.
cogl_texture_get_format() has been deprecated, so rather than using
it to figure out beforehand whether the buffer format is supported,
just rely on the import failing if it isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=722347
We need to set the number of components on the CoglTextureRectangle to
prevent wasting too much GPU memory. As we need to do this before we call
cogl_texture_set_region, just remove the meta_texture_rectangle_new wrapper,
and make callers call cogl_texture_rectangle_new_with_size directly.
When GDK sends an unmaximize _NET_WM_STATE ClientMessage, it tells us to remove
the _NET_WM_STATE_MAXIMIZED_HORZ and _NET_WM_STATE_MAXIMIZED_VERT states. Before
this time, it would independently call:
meta_window_unmaximize (window, META_MAXIMIZE_HORIZONTAL);
meta_window_unmaximize (window, META_MAXIMIZE_VERTICAL);
Which, besides being foolishly inefficient, would also mess up our saved_rect
tracking, causing the window to only look like it was unmaximized vertically.
Make this code more intelligent, so it causes us to unmaximize in one call.
https://bugzilla.gnome.org/show_bug.cgi?id=722108
This grab was added in commit caf43a123fhttps://bugzilla.gnome.org/show_bug.cgi?id=381127
to minimize window flickering when switching workspaces.
While this grab is held, some signals are emitted to the shell,
which can lead to deadlocks (reproduced under Mali binary OpenGLESv2
drivers).
Now that we are a compositing window manager, we do not have to
worry about flickers, this grab should no longer be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=721709
Under some circumstances, for example when the display controller driver
doesn't report back the correct EDID, or under VirtualBox, Mutter
returns suboptimal strings for an output display name, leading to funny
labels like 'Unknown 0"', or '(null) 0"' in the Settings panel.
This commit improves our heuristic in three ways:
- we now avoid putting inches in the display name if either dimension is
zero
- we use the vendor name in case we're not able to lookup its PnP id
from the database. Previously we would have passed over '(null)'
- as a special edge-case, when neither inches nor vendor are known, we
use the string 'Unknown Display'
Finally, we make the combined vendor + inches string translatable, as
different languages might want to move the size part of the string to a
position different than the end.
https://bugzilla.gnome.org/show_bug.cgi?id=721674
Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.
During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.
When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).
The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The return code of XGetWindowAttributes() indicates whether an error
was encountered or not. There is no need to specifically check the error
trap.
The trap around XAddToSaveSet() was superfluous. We have a global error
trap to ignore any errors here, and there is no need to XSync() as GDK
will later ignore the error asynchronously if one is raised.
Also move common error exit path to an error label.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
In meta_screen_manage_all_windows() we can use our own stack
tracker to get the list of windows - no need to query X again.
A copy is needed because the stack gets modified as part of the loop.
Specifically, meta_stack_tracker_get_stack() at this time returns the
predicted stack, and meta_window_new() performs a few operations
(e.g. framing) which cause immediate changes to the predicted stack.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.
But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().
Remove the unnecessary grab.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
Server grabs are not as evil as you might expect, but there is agreement
in that their usage should be limited.
Server grabs can cause things to go rather wrong when mutter emits
a signal while it has grabbed the server. If the receiver of that signal
waits for a synchronous action performed by another client, then you
have a deadlock. This happens with Mali binary GLESv2 drivers :(
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.
As that doesn't happen any more, we can clean up. No functional changes.
Suggested by Owen Taylor.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
When we move focus elsewhere when unmanaging a window, we *need* to move
the focus, so if the target is globally active, move the focus to the
no-focus-window in anticipation that the focus will normally get moved
to the right window when the target window responds to WM_TAKE_FOCUS.
If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left
on the no-focus-window, but there's no way to distinguish whether the
app will respond or not.
https://bugzilla.gnome.org/show_bug.cgi?id=711618
When a client spontaneously focuses their window, perhaps in response
to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
Updating display->focus_serial in response to FocusOut then was causing
us to ignore FocusIn and think that the focus was not on any window.
We need to distinguish this spontaneous case from the case where we
set the focus ourselves - when we set the focus ourselves, we're careful
to combine the SetFocus with a property change so that we know definitively
what focus events we have already accounted for.
https://bugzilla.gnome.org/show_bug.cgi?id=720558
Initial placement during meta_window_constrain() can result in changes
to the borders, so we need to recompute our border sizes after
constraining. This fixes incorrect window borders on
initially maximized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=720417
Currently the only way to move a window to another monitor via
keyboard is to start a move operation and move it manually using
arrow keys. We do have all the bits of a dedicated keybinding in
place already, so offer it as a more comfortable alternative.
https://bugzilla.gnome.org/show_bug.cgi?id=671054
The shadow is added in the paint step, not as a separate actor,
so the raise is a no-op. It also gets rid of an annoying misspelling
that's driving me crazy.
Some drivers which support RandR 1.4 may not support setting
or getting the primary output, therefore mutter should trap
and ignore any relevant errors.
The modesetting driver exposes this problem when used in
combination with the nvidia binary driver using RandR 1.4
offloading.
Also use a local display variable instead of calling
meta_get_display () every time.
When unmaximizing, we changed bits of window state, then called out
to code that used the frame extents *before* we cleared old cached
extents. Clear the cache up-front as soon as we change the window
state.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
In the past, MetaWindowGroup was allocated the size of the screen and
painted the size of the screen because it contained the screen background,
but now we also have the "top window group" which contains only popup
windows, so the allocation doesn't properly reflect the paint bounds
of the window group. Compute the paint bounds accurately from the
children.
https://bugzilla.gnome.org/show_bug.cgi?id=719669
When _GTK_FRAME_EXTENTS changes, we need to redo constraints on
the window - this matters in particular if the toolkit removes
invisible borders when a window is maximized, since otherwise
the maximized window will be positioned as if it still has
invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
Instead of hardcoded knowledge of certain classes in MetaWindowGroup,
create a generic interface that all actors can implement to get parts of
their regions culled out during redraw, without needing any special
knowledge of how to handle a specific actor.
The names now are a bit suspect. MetaBackgroundGroup is a simple
MetaCullable that knows how to cull children, and MetaWindowGroup is the
"toplevel" cullable that computes the initial two regions. A future
cleanup here could be to merge MetaWindowGroup / MetaBackgroundGroup so
that we only have a generic MetaSimpleCullable, and move the "toplevel"
cullability to be a MetaCullableToplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=714706
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
Instead of passing around MetaFrameBorders, compute it when we need it.
This also allows us to know that we are using MetaFrameBorders only for windows
with frames (where it is meaningful) and not for frameless windows, which
can have custom borders which we need to interpret differently.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
Cache the computed border size so we can fetch the border size at
any time without worrying that we'll be spending too much time in
the theme code (in some cases we might allocate a PangoFontDescription
or do other significant work.)
The main effort here is clearing the cache when various bits of window
state change that could potentially affect the computed borders.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
There are extensive places in the code where we convert between the client
rectangle and the frame rectangle. Instead of manually doing it use
new helper functions on MetaWindow and the existing meta_window_get_outer_rect().
This fixes a number of bugs where the computation was being done incorrectly,
most of these bugs are with the recently added custom frame extents, but
some relate to invisible borders or even simply to confusion between the
window and frame rectangle.
Switch the placement code to place the frame rectangle rather
than the client window - this simplifies things considerably.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
What we want to achieve is that the dialog is visually centered
on the parent, including the decorations for both, and making sure
that CSD/frame_extents are respected.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
Use the "hotplug_mode_update" connector property indicating that the
screen settings should be updated: get a new preferred mode on hotplug
events to handle dynamic guest resizing (where you resize the host
window and the guest resizes with it).
https://bugzilla.gnome.org/show_bug.cgi?id=711216
Any files matching the previously used globs are no longer distributed,
breaking distcheck. Match the actual sources in compositor/, core/, meta/
and ui/ instead.
Clients like on-screen keyboards try not to take focus when the user clicks
on their window by setting the Input hint to false. However, due to GTK+ and
GDK bugs, the public API for setting the Input hint to false don't remove
WM_TAKE_FOCUS from WM_PROTOCOLS, unintentionally putting them into Globally
Active mode.
These clients also expect that since they don't want to take focus, they want
the focus to remain on the existing window. In this case, for clients like
on-screen keyboards, it's so they can send synthesized keyboard events to the
focused window.
https://bugzilla.gnome.org/show_bug.cgi?id=710296
Expose min-backlight-step so that gnome-settings-daemon can
support backlights with less than 10 steps without mutter
normalizing the brightness back to its original value
https://bugzilla.gnome.org/show_bug.cgi?id=710380
Rather than do the cursor -> name translation ourselves in two different
places, use the facilities in libXcursor to do it for us. Put the shared
piece of code in meta-cursor-tracker, and use it for both server-side and
client-side cursor loading.
Apparently some connector technologies don't distinguish between
on and off, and there might be valid use cases for running without
any connected monitor.
In that case, just avoid any configuration at all.
https://bugzilla.gnome.org/show_bug.cgi?id=709009
The part of code dealing with move/resize grab in display.c is only
responsible of this behavior when triggered with a modifier. So it
shouldn't stop the move/resize behavior triggered from a mouse event
without modifier on the title bar or sides of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=704759
The current time offset calculation is wrong. It is supposed to calculate
the offset between the current time and the
"time where it message should be sent" (last_time + interval).
Fix the math to actually do that.
https://bugzilla.gnome.org/show_bug.cgi?id=709340
The destroy notify for a DBus watch holds a reference to the IdleMonitor,
but the IdleMonitorWatch object doesn't (it knows all watches will
be destroyed before the monitor is, so it doesn't need one). This
means that the DBus watch reference can be the only one keeping
the IdleMonitor alive (expecially true for device idle monitors,
which are only used by g-s-d/cursor), and that means that calling
the destroy notify freezes the monitor (and the next X calls
access garbage).
https://bugzilla.gnome.org/show_bug.cgi?id=708420
If you maximize a CSD window on a monitor without struts, it ends
up taking the whole monitor size, but it doesn't mean that the
application wants to fullscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=708718
We must set size_changed even if we are frozen, as every window
size change makes the X server drop the pixmap, and we might lose
the information at the next thaw() if the window changes size
twice in one frame (so we would keep drawing with the old pixmap
until something else causes another resize)
Fix done together with Giovanni Campagna <gcampagn@redhat.com>
Need two passes, because the order we traverse the array is
alphabetical on connector name, not left to right, so we might
see a monitor on the right before we get the offset from disabling
the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=707473
The XSync semantics mandate that alarms already expired will not
fire until the counter is reset and the alarm triggered again, so
clients traditionally called get_idle_time() first to see if they
should install the alarm.
This is inherently racy, as by the time the call is handled by
mutter and the reply received the idle time could be different.
Instead, if we see that the watch would have fired in the past,
fire it immediately.
This is a behavior change, but it's a compatible one, as all legacy
clients are calling get_idle_time() first, and it was perfectly
possible for the idle time counter to trigger the alarm right
after the get_idle_time() call.
https://bugzilla.gnome.org/show_bug.cgi?id=707302
We don't get notifications from X11 when the mode is reset, so
our cached value can get stale. To work around that, always forward
requests to the backend (and let it deal with ignoring the change
if wanted)
https://bugzilla.gnome.org/show_bug.cgi?id=707649
clutter_stage_show_cursor()/hide_cursor() only works in the X11
backend (where someone else is in charge of showing the cursor),
and even then, it has confusing effects when running nested wayland,
so an abstraction layer is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=707474
No, holes in the framebuffer are not a good a thing: windows can
get lost there, and the user can get very confused.
Instead, compact the monitors that where previously after.
https://bugzilla.gnome.org/show_bug.cgi?id=707473
The meta_create_texture_pipeline function used to create a dummy 1x1
texture so that it could make sure that the all of the state that
affects the shader generation would be set on the template pipeline so
that Cogl could share the pipeline's shader with any other pipelines
that are just rendering a texture. This is no longer necessary because
the only thing that affects the shader generation is the texture type,
not the actual texture data and Cogl now has a function to explicitly
set the texture type which we can use instead. Additionally even if
the template mechanism is not used at all Cogl will still end up
reusing the same shader because it now has a shader cache which is
indexed by the pipeline state so pipeline's don't strictly need to
share ancestry in order to take advantage of it. However we still
might as well use the function because if there is a common ancestry
it is faster to look up the shader because Cogl doesn't need to hash
the pipeline state.
https://bugzilla.gnome.org/show_bug.cgi?id=707458
If, checking the event timestamps, we see that a new configuration
was explicitly requested by an another XRandR client, don't proceed to
apply the intended configuration again, even if looking at the
EDIDs it appears that the outputs changed.
This works around some buggy Xorg drivers (qxl, vbox) that generate
a new serial number everytime the user resizes the host window.
https://bugzilla.gnome.org/show_bug.cgi?id=706735
A gulong is not enough to get 64 bits in all arches, so we must
cast it, or we can corrupt the stack.
This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055
https://bugzilla.gnome.org/show_bug.cgi?id=707267
device_id_max is set to the device_id in ensure_device_monitor(), but we
will loop only to (device_id_max - 1) when propagating the sync XEvent
down, missing the device correspondng to device_id_max.
https://bugzilla.gnome.org/show_bug.cgi?id=707250
cairo_region_copy, while valid to call on a NULL pointer, gives us an empty
region instead of an infinitely big region, so the interesction won't give
us what we want. Just check for this case explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=707081
When drawing entirely opaque regions, we traditionally kept blending on
simply because it made the code more convenient and obvious to handle.
However, this can cause lots of performance issues on GPUs that aren't
too powerful, as they have to readback the buffer underneath.
Keep track of the opaque region set by windows (through _NET_WM_OPAQUE_REGION,
standard RGB32 frame masks or similar), and draw those rectangles
separately through a different path with blending turned off.
https://bugzilla.gnome.org/show_bug.cgi?id=706930
Split out pipeline creation to a separate function so that we don't
have so much dense code in the paint function itself, and remove some
indentation levels.
Also, don't use our own template for the unmasked pipeline, since it
has nothing different from the default pipeline template.
We also don't store the pipelines anymore since their creation isn't
really helping us; we set the mask texture and paint texture on every
paint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=706930
As part of Wayland support, we should hold the shape and opaque regions
on the MetaWindow rather than fetching them in the MetaWindowActor, as
this gives us better flexibility as to where the regions are set, and
allows for easier Wayland support.
To make merging easier with the Wayland branch, we also append the _x11
suffix to functions that use the X SHAPE extension to fetch the shaped
regions.
https://bugzilla.gnome.org/show_bug.cgi?id=706930
We must send frame_drawn and frame_timing messages to even when
we don't actually queue a redraw on screen to comply with the
WM sync spec.
So throttle such apps to down to a ~100ms interval.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
When we get a damage event we update the window by calling
meta_shaped_texture_update_area which queues a redraw on the actor.
We can avoid that for obscured regions by comparing the damage area to
our visible area.
This patch causes _NET_WM_FRAME_DRAWN messages to be not sent in some cases
where they should be sent; they will be added back in a later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
The user active watch is a one-fire watch, but it is valid in the API
for the callback to explicitly remove the watch itself. In that case,
the watch will be invalid after the user removes it, and the memory
potentially freed. So make sure to not dereference the watch after
the callback is called.
https://bugzilla.gnome.org/show_bug.cgi?id=706825
Dialogs that don't have a parent should not be skip-taskbar,
otherwise they get lost and there is no way to recover them
(because they're not autoraised when activating the parent),
but toolkits and applications set the hint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=673399
Due to changes in gnome-common git, an implicit m4 directory is no
longer created during autogen. The attached patch explicitly and
correctly specifies a macro directory.
https://bugzilla.gnome.org/show_bug.cgi?id=706787
If we're attempting to reconfigure the CRTCs to the same parameter,
skip the X call, as in some drivers a modeset can take time and
cause flicker.
https://bugzilla.gnome.org/show_bug.cgi?id=706672
To allow other clients (gnome-session, gnome-settings-daemon)
to monitor user activity, introduce a DBus interface for the
idle monitor inside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
When running as a wayland compositor, we can't use the xserver's
IDLETIME, because that's updated only in response to X events.
But we have all the events ourselves, so we can just run the timer
in process.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
Each level in the tower is initialized by binding the texture for that
level to an offscreen framebuffer and rendering the previous level as a
textured rectangle. The problem was that we were blending the previous
level with undefined data so argb32 windows with transparencies would
result in artefacts. This makes sure to disable blending when drawing
the textured rectangle.
We can't really support the Gtk+ automatic scaling, as to much
code relies on the GdkWindow and XWindow sizes, etc to match.
In order to keep working we just disable the scaling, meaning
we will pick up the larger fonts, but nothing else. Its not
ideal but it works for now.
https://bugzilla.gnome.org/show_bug.cgi?id=706388
Remove grab window and cursor from the API, and just grab always
on the stage window with no cursor.
This is mainly to remove the X11 usage in the public API, in preparation
for implementing this in wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=705917
Using out-of-band notifications from the wayland protocol or from
X is racy, in that the client could ask for the new resources before
we have them.
Instead, with a signal, we are sure that when the client asks for
it, it will get the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=706382
Under X, we need to use XFixes to watch the cursor changing, while
on wayland, we're in charge of setting and painting the cursor.
MetaCursorTracker provides the abstraction layer for gnome-shell,
which can thus drop ShellXFixesCursor. In the future, it may grow
the ability to watch for pointer position too, especially if
CursorEvents are added to the next version of XInput2, and thus
it would also replace the PointerWatcher we use for gnome-shell's
magnifier.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
