[compiz] window matching interface and the new match option
mike at blueroot.co.uk
Tue Feb 27 08:26:25 PST 2007
Bellegarde Cedric wrote:
> On Tuesday 27 February 2007 15:03:02 Mike Dransfield wrote:
>> It just sets the atoms
>> which core responds to, so it is just a hack.
> It's exactly what is doing compiz core with opacity...
> Look at increaseSaturation() and inceaseOpacity(), the code is the same... So
> bs code comes from compiz core, i see no reason to have this in core...
I think that part is the candidate to be removed into a plugin
but I do not think it would not bring much benefit.
For users who do not manually modify brightness and saturation,
it would actually be a larger overhead.
My point is that most of the window painting stuff is handled by
core, so to really have an opacity/brightness/saturation plugin, you
should remove either all the functionality or none of it. As I said
the option to change it is different from the actual functionality to
do it. Having half the functionality in core and half in a plugin with
separate code paths would lead to problems.
I think that the benefit/loss is so marginal in each way that we should
keep the status quo, unless there is a really good reason to pull this out?
If you were going to pull that out, you could as easily pull out the window
close/maximize options and continue with most of them.
More information about the compiz