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
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
