lp://staging/~robertcarr/compiz-core/with-stackfixes

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

2818. By Robert Carr on 2011-09-15

Merge latest trunk

2817. By Sam Spilsbury on 2011-09-15

Merge in further stacking fixes

2816. By Sam Spilsbury on 2011-09-14

Merge in more stacking fixes

2815. By Sam Spilsbury on 2011-09-12

Manage windows from bottom to top again.

Managing them this way makes debugging more of a pain, but core has a preference
for managing windows such that they'd be on top of everything on the stack, so
don't mess with that.

2814. By Sam Spilsbury on 2011-09-12

Merge in destroyed windows fix

2813. By Sam Spilsbury on 2011-09-10

Merge in StackDebugger stack sanity checker

2812. By Sam Spilsbury on 2011-09-10

Bump ABI since we added a new mfunc

2811. By Sam Spilsbury on 2011-09-10

Fix a typo that was causing decoration frames to be added as normal windows (causing
stack sync problems) and improve the heuristics of the stack sync debugger

2810. By Sam Spilsbury on 2011-09-10

Fix typo

2809. By Sam Spilsbury on 2011-09-10

Immediately remove destroyed windows from the stacks last sent to the server
and last received from the server.

Having destroyed windows there was used as a means to have plugins keep references
to them for, eg, close animations. However, keeping them there meant that we needed
to resort to ugly hacks like setting the id to 0 and explicitly ignoring them in the
plugins if they were destroyed. It also meant that there could be stack sync problems
since a window could be restacked relative to an older destroyed window that was still
in the stack.

Now destroyed windows are pushed into a separate stack in the API and accessible only
through there. The composite plugin was also changed to paint both referenced destroyed
windows (since their textures are still valid) and also normal windows in the case
that there are referenced destroyed windows. This may require some changes in plugins
which might use screen->findWindow () or screen->windows () in order to locate or
process destroyed windows - they should use the composite plugin's getWindowPaintList
instead or also process screen->destroyedWindows ()