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