compiz - May 2007 - [PATCH] add 'sticky' mode to cube to allow sticky+not-on-bottom windows to stick to the screen when the screen is transformed

I've attached the patch since I don't yet have an easy way to make git 
format-patch and kmail play nice together.  The basic idea is during a 
rotate/other cube transform, 'sticky' windows stick to the screen
instead of
being redrawn once per face (its an option, the default is the old behaviour)

Consider this, please, essentially an RFC - this particular behaviour was 
available previously in Beryl, and was (at least according to 
screenshots/casts) widely used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-sticky-mode-to-cube-to-allow-sticky-not-on-bot.patch
Type: text/x-diff
Size: 6357 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20070527/271b898f/attachment.patch

On Sun, 2007-05-27 at 19:41 -0400, Quinn Storm wrote:
> I've attached the patch since I don't yet have an easy way to make
git
> format-patch and kmail play nice together.  The basic idea is during a 
> rotate/other cube transform, 'sticky' windows stick to the screen
instead of
> being redrawn once per face (its an option, the default is the old
behaviour)
> 
> Consider this, please, essentially an RFC - this particular behaviour was 
> available previously in Beryl, and was (at least according to 
> screenshots/casts) widely used.
Yea, this behavior makes a lot of sense for sticky windows. The problem
is that during cube motion these windows suddenly becomes on top of
windows that they are normally stacked below and that looks pretty bad
unless it's animated.

I think it will look better if the cube is moved back a bit during
motion like when windows are being elevated and maybe it makes more
sense to make this functionality part of the 3D plugin, which btw should
hook into the cube plugin the same way rotate plugin now does.

-David

On Fri, 2007-06-01 at 08:22 +0800, Sam Spilsbury wrote:
> Does this mean that cube zoom will be implimented?
> I remember a while back it was implimented using switchers zoom
> functionality, probably not implimented the right way.
> 
> 3D still requires PAINT_WINDOW_FRONT_TO_BACK_MASK to work properly
> however. Is there a chance that anyone can get this and transcube
> fixed up?
PAINT_WINDOW_FRONT_TO_BACK_MASK is not going to be added but I
definitely like to see both the window elevation and translucent cube
functionality supported sometime soon. It should be a lot easier to get
this working properly now that the cube plugin can export any hooks we
find useful.

-David