[compiz] window matching interface and the new match option
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
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).
More information about the compiz