Bellegarde Cedric wrote:
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.
I think we will still need a state plugin, maybe other plugins
could take care of some things like initial viewport, but there
are some things which we would want to do which would not
fit into any plugin.
If you look at KDE's window specific settings then look at the tabs
labeled workarounds and preferences, you can see all the things
that state can still take care of. They are basically hacks to
windows a lot like what state has now. I am only using KDE as
an example because I know it is very comprehensive (and I have it
here), I have no idea about metacity.
State might eventually be able to fix certain toolkit bugs with
a config line rather than having to code the workarounds into
either core or the plugins.
If we had the ability to match override redirect windows then
we could fix the mozilla menu bug without code.
Another thing, for now, opacity increase/decrease is in core, i think it
should go in bs plugin (rename it bso plugin).
Or you could call it the obs plugin ;)
I have been giving this one a lot of thought and this is my
conclusion.
The bso plugin should not exist because it does not actually
do the work of changing the paint values. It just sets the atoms
which core responds to, so it is just a hack.
I personally think the actions for bs should be in core, but on
the other hand, how useful would they be? If they are not used
by most people then to them it is just bloat. I think changing the
opacity is very common but not brightness or saturation.
_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
