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

[Danny Baumann]

Hi,

> > - 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?

In Beryl, the following plugins use grab/ungrab notifies:
- group for determining which window inside the group is moved/resized
by the user
- water for a "ungrab window wave" effect
- animation & snap for determining user initiated moves/resizes (same as
group)

I believe plugins need at least some means to distinguish between a
user-initiated action and a non-user-initiated action. IMO, the grab
interface even makes sense ;-)

> > - 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. 

You are right; however, for some cases, plugins need to be aware of
other plugins actions (such as the aforementioned move and resize
actions). Perhaps we should put a comment inside of compiz.h with a
disclaimer to use this function only where absolutely necessary ;-)

> > - 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.

I mean byte-order. And yes, you are right that the function doesn't do
the reordering by itself. But the problem is that for hard-coded
textures the byte ordering isn't native, but determined by the CPU the
texture header was created on; so for this cases, we would need to tell
GL that the format always is GL_RGBA and not native.

Regards,

Danny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screengrabexist.patch
Type: text/x-patch
Size: 1961 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070306/5a05e7a5/screengrabexist.bin