| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4943d79d6844af3f7fc0a15ceadb69d95c4c5c61.
https://bugzilla.gnome.org/show_bug.cgi?id=461927
This bug had two testcases that now seems to work fine.
https://bugzilla.gnome.org/show_bug.cgi?id=760510
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Same code before 8b0ed193cfa771ec1f3ba70b272b9b14e02e6d3c commit
was protected with error trap. Add it back.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.
Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.
|
|
|
|
|
|
|
|
|
| |
When restacking the last window alone, we would trigger this off-by-one
error. This would throw us off the end of the array, causing lower_below
warnings for nonsensical values.
Since the last window already is lowered below everything else, we
shouldn't need to lower it.
|
|
|
|
| |
These are unused elsewhere.
|
|
|
|
|
|
|
|
| |
Now that all actual stack shuffle is handled inside stack-tracker.c, we can make
meta_stack_tracker_record_[raise_above/lower_below] internal to that file and
remove the unused meta_stack_tracker_record_lower().
https://bugzilla.gnome.org/show_bug.cgi?id=736559
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=04bc846ef366964505abbb016c383becfb5fca88
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=9401196e88503d07c5252f4c904a03ade6c531ea
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=34573660665ba4134451cc82a596367dbf3989d0
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=cb66cf6398f4a870ff6e7c0f7acab5b71a3f98ad
|
| |
|
| |
|
| |
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=043a201f9088ac73670d7abe0318c4e00813c81c
|
|
|
|
|
|
|
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=40e820f551e5d02dc8d9eecb55419fe00558c670
https://git.gnome.org/browse/mutter/commit/?id=b53bf0e8c2f84c93acbef5cb9d08fedce80b8013
https://git.gnome.org/browse/mutter/commit/?id=0be4622e14af0625472123dadb0648e25501f764
https://git.gnome.org/browse/mutter/commit/?id=a378faf495351244189ba893e8e7c2733e7311a6
https://git.gnome.org/browse/mutter/commit/?id=098c8908edf01a515d862bff1e8d37cd227370a9
https://git.gnome.org/browse/mutter/commit/?id=9711d95996c9ae3f0ccf5f82d2bb9aa7a5dda00f
https://git.gnome.org/browse/mutter/commit/?id=01b6d9bfe2dcb8c806c13877d2816edd7876ceec
https://git.gnome.org/browse/mutter/commit/?id=d1a588a94fba75c21a6b26b30a73c2087ad0c4e5
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We might receive ConfigureRequest to change only window stacking
order. According to ICCCM section 4.1.5 we should send synthetic
ConfigureNotify event.
https://bugzilla.gnome.org/show_bug.cgi?id=582580
|
|
|
|
| |
It was never turned on for all the years it's been there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
https://git.gnome.org/browse/mutter/commit/?id=f9568535509e40a35e9a875b4d91686ab2969e42
|
| |
|