Here is a switcher patch to disable window list:
It's very useful if you set opacity to 0. Then, window just bring to front
one
by one while switching. It's much more usable, i think, that small
miniatures
in a list where you don't see anything.
While making this patch, a question come into my head, nobody know on
compiz.biz and some people are as curious as me.
Two code example:
/**********/
case SWITCH_SCREEN_OPTION_MIPMAP:
case SWITCH_SCREEN_OPTION_ICON:
case SWITCH_SCREEN_OPTION_MINIMIZED:
if (compSetBoolOption (o, value))
return TRUE;
break;
/**********/
/**********/
case SWITCH_SCREEN_OPTION_BRINGTOFRONT:
if (compSetBoolOption (o, value))
{
ss->bringToFront = o->value.b;
return TRUE;
}
/**********/
At first look, i tell me: "How plugin know that MINIMIZED option had change
if
we do nothing more than returning TRUE. After looking the code, i saw this:
ss->opt[SWITCH_SCREEN_OPTION_MINIMIZED].value.b
So my question is:
When do i have to directly read CompOption?
When do i have to add a member to my plugin struct and update it in
pluginSetScreenOption() ?
Cedric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: switcher.patch
Type: text/x-diff
Size: 6138 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20061111/2d97a036/switcher.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiz.schemas.zoom.patch
Type: text/x-diff
Size: 889 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20061111/2d97a036/compiz.schemas.zoom.bin
Ok, i rewrite the patch, it was so bad in fact, i think. Please have a look at this one and tell me if it seems good. Cedric -------------- next part -------------- A non-text attachment was scrubbed... Name: switcher.patch Type: text/x-diff Size: 3711 bytes Desc: not available Url : http://lists.freedesktop.org/archives/compiz/attachments/20061112/1321bee0/switcher.bin
On Sat, 2006-11-11 at 23:49 +0100, Bellegarde Cedric wrote:> Here is a switcher patch to disable window list: > > It's very useful if you set opacity to 0. Then, window just bring to front one > by one while switching. It's much more usable, i think, that small miniatures > in a list where you don't see anything. > > While making this patch, a question come into my head, nobody know on > compiz.biz and some people are as curious as me. > > Two code example: > > /**********/ > case SWITCH_SCREEN_OPTION_MIPMAP: > case SWITCH_SCREEN_OPTION_ICON: > case SWITCH_SCREEN_OPTION_MINIMIZED: > if (compSetBoolOption (o, value)) > return TRUE; > break; > /**********/ > > > /**********/ > case SWITCH_SCREEN_OPTION_BRINGTOFRONT: > if (compSetBoolOption (o, value)) > { > ss->bringToFront = o->value.b; > return TRUE; > } > /**********/ > > At first look, i tell me: "How plugin know that MINIMIZED option had change if > we do nothing more than returning TRUE. After looking the code, i saw this: > > ss->opt[SWITCH_SCREEN_OPTION_MINIMIZED].value.b > > So my question is: > When do i have to directly read CompOption? > When do i have to add a member to my plugin struct and update it in > pluginSetScreenOption() ?Well, ss->opt[SWITCH_SCREEN_OPTION_MINIMIZED].value.b is the real storage for the option value. There's usually no reason to keep a copy of it in another variable, it's just a waste of memory. In some cases a different value needs to be computed from the actual option value and it then makes sense to do this when the option is changed. In some cases, I probably make a copy of option values to clean up the code but that's just me being lazy and not recommend. It's much better to put a temporary variable on the stack to clean up code than putting a variable in the heap allocated screen and display structures. So I much prefer your first code example. I should probably fix my code so this is consistent. -David