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 _______________________________________________ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
