[compiz] window matching interface and the new match option

[Mike Dransfield]

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.