[compiz] window matching interface and the new match option

Bellegarde Cedric gnumdk at puffy.homelinux.org
Mon Feb 26 23:51:57 PST 2007


On Tuesday 27 February 2007 01:43:32 Mike Dransfield wrote:
> It would also be very useful if the match string could include a
> value as well.  This would mean that plugins like blur could
> have a list of matches with values and it could apply different
> types of blur to different types of windows.  eg.  It could use
> 4xBilinear for any window which is wider than 500 px like this
>
> min_width=500 =4xBilinear
>
> The core could always parse this as a string and then the plugin
> can convert it to the type that it requires.  I think it would be useful
> for almost all the plugins that use window matching (fade could have
> different fade speeds for different window types).

I agree with you, we need this...

Another question, do we need a state plugin?
blur, switcher, ... now use "window matching"  to enable/disable effect. With 
your proposition, we should be able to specify blur type.

So, with window matching, bs plugin should set brightness/saturation, place 
plugin should set window position/stacking, decoration plugin should set 
decorations, ...

So my question is: Should we have a state plugin or should we have a per 
plugin window matching? I know it will increase plugin size, but i think it 
should make compiz configuration much more consistent (instead of having some 
matching in plugins and some matching in state)

Another thing, for now, opacity increase/decrease is in core, i think it 
should go in bs plugin (rename it bso plugin).

Cedric


More information about the compiz mailing list