Created by Sam Spilsbury and last modified
Get this branch:
bzr branch lp:~smspillaz/compiz-core/oneiric.20110927_fixes
Only Sam Spilsbury can upload to this branch. If you are Sam Spilsbury please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Sam Spilsbury
Compiz Core

Recent revisions

2821. By Sam Spilsbury

Support the case where a normal window marks itself a transient of a dock. In that
case we should stack that window above the dock since it may be an IM window.

2820. By Sam Spilsbury

Since we can reliably tell when windows are pending a restack, use that
to determine if we should restack relative to this window anyways.

2819. By Sam Spilsbury

Since we are the only one to make ConfigureWindow requests on toplevels which the
server will actually obey, it is possible track outgoing ConfigureWindow requests
and match them to incoming ConfigureNotify events, assuming that priv->geometry
and priv->serverGeometry ONLY represent what was last sent to the server and what
was last received. Which allows us to effectively fix the race conditions
which made positioning and stacking unpredictable at times.

As such, any plugins past this commit, need to be careful not to modify w->geometry
or w->serverGeometry directly. Unfortunately, the move plugin is a serial offender in
this area and will update w->serverGeometry directly after doing w->move, which causes
race conditions when other plugins try to configure a window through the server first.

This change ensures that when there are pending ConfigureNotify events, no synchronous
updates of the window geometry are allowed. For plugins that do touch w->serverGeometry
for whatever reason, a lock_geometry call is sent through handleCompizEvent whenever
there are pending ConfigureNotify events for plugins not to do that. This will remain
in place until we can break ABI/API and prevent plugins from doing that.

2818. By Sam Spilsbury

Notify plugins of unreparenting after we invalidate the frame reference
otherwise they may call through to configureXWindow or updateFrameWindow
which will move the client to 0x0 in "local" co-ordinate space (eg, in
the root window)

2817. By Sam Spilsbury

Use w->geometry () as a base for movement rather than serverGeometry as
plugins may update this out of sync with what we're doing and this can
cause us to send incorrect ConfigureWindow requests.

Using w->geometry () here is safe since that's updated synchronously
with w->move ()

2816. By Sam Spilsbury

Determine the desired window geometry using geometry last sent from server
at the time the timer is called and not before we call the timer.

There is a race condition where the server geometry could be updated after
after we register the timer for decorOffsetMove, this would cause unpredictable
behaviour with maximization where decoration size changes occurred.

2815. By Sam Spilsbury

Allow other plugins to draw decorations on windows that may not have received damage
events yet, but don't draw the undamaged window itself.

Rationale: Some (buggy) applications may map windows which have not yet been
drawn on, this would cause their input shape and frame window to block input
for other applications. This makes it clear to the user that that window
*is* there, so they can deal with it appropriately. For the largest usecase
of requiring a damage event before displaying a window which is override redirect
windows, this commit has no effect since those window don't get decorations anyways.

2814. By Sam Spilsbury

Merge upstream -r2828..2833

2813. By Sam Spilsbury

Revert experimental code

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.