[compiz] [PATCH] Grab state & Last state remembering

[David Reveman]

On Mon, 2007-03-05 at 17:07 +0100, Danny Baumann wrote:
> Hi,
> 
> while porting "Group with tabs" to Compiz
> (http://forum.go-compiz.org/viewtopic.php?t=649), I noticed some things
> which are available in Beryl, but not in Compiz and which I believe
> Compiz should have, too:
> 
> - Remembering of the last window state inside the state change notify
> This is useful for properly tracking down the window state changes (e.g.
> has the window been maximized in that state change?). In Beryl, we added
> a variable lastState into CompWindow, which is updated inside core's
> stateChangeNotify. The attached last-window-state.patch brings that
> behaviour to Compiz.

I've applied the patch. However, all code that cause a change to the
state should be modified so that a mask of changed bits can be passed to
the state change notify function instead. This lastState variable
shouldn't have to exist.

> 
> - Remembering the grabbing state
> Previously, only one window could be grabbed at a certain time. However,
> when using group, a number of windows can be grabbed at a certain time,
> so I think it's useful to provide this information to all plugins
> without requiring them to wrap into the grab / ungrab notifies.

Applied this too but the whole grab/ungrab window interface is probably
a big mistake to start with. It was sort of a simple hack to get the
wobbly plugin working a long time ago. Do we have other plugins that use
this today?

> 
> - Resize diff information
> I sent this patch to the list before, may I ask if it could be
> commited? ;-)

done.

> 
> Additionally, some more things are needed for group (and probably other
> plugins), which I currently solved locally (inside group), but believe
> that it would make sense to put them inside core:
> 
> - A function screenGrabExists
> This function, as the name implies, checks if a certain plugin has a
> screen grab. It's pretty similar to otherScreenGrabExists and could
> share a lot of code with it. We need this kind of functionality in group
> to distinguish between user initiated / non user initiated window
> moves / resizes; but I can imagine that this kind of function could come
> in handy to other plugins as well.

This is probably OK. I'm a bit reluctant to adding things that provide
functionality that allow plugins to know about other plugins. I believe
that the more dependencies between plugins we have the harder it's going
to be to maintain and keeps things stable. 

> 
> - A fixed byte ordering image loading
> In group, we have some hard-coded textures (for glow) inside a header
> file which - obviously - have a fixed byte ordering. If those textures,
> generated on an Intel CPU, are displayed on a PC using a PPC CPU, the
> byte ordering is reversed by the function imageToTexture causing the
> texture being displayed incorrectly. In my opinion, it would make sense
> to add a parameter to the function imageBufferToTexture which
> enables/disables this byte swapping inside imageToTexture.

Do you mean the byte-order or scanline-order? That function will not do
any byte swapping it will only tell the GL that the data is in native
byte order.

- David