[compiz] BlurFX for compiz

[Mike Dransfield]

Jigish Gohil wrote:
> On 10/5/06, Mike Dransfield <mike at blueroot.co.uk> wrote:
>> I do not mind maintaining these 2 plugins somewhere separate.  I would
>> prefer that they were included in the main tree so that they are in the
>> default install but I understand Davids reasons.  I can maintain them to
>> keep working with compiz and to add bug fixes etc but at some point they
>> might have to be separated when they would need a proper maintainer.
>
> I have been thinking about the same thing for some time, to get all
> the beryl plugins 100% compatible with compiz.
>
> How about an idea that we start a branch of beryl on beryl svn server
> and enlist the help of all the plugin developers too?
>
> This would be like the good old days of compiz-quinn.

I would also like this, I do not agree with the fork personally.  The 
problems that I have are not so much technical as informational.  
Changes have been made to the original compiz source which do not seem 
to have a valid reason.  There are many examples which I can think of 
which seem utterly pointless and only make it harder to work out what is 
going on and to make beryl plugins work on compiz.  My personal pet 
hates are.

1.  So many whitespace changes, tabs to spaces, function declarations 
put back onto one line makes it look like there are more changes than 
there are.
2.  API versioning, this decision seems to have only been made based on 
pride.  This was one of the few technical decisions that was made in a 
public recorded way.  All other decisions seem to have been made in 
IRC.  http://forum.beryl-project.org/topic-4585-plugin-binary-version-check
3.  Changing of the key bindings code for seemingly no benefit.  The 
keysym storage method was changed to keycodes.  This makes it very hard 
to write third party apps which do not link to X.  Changing it back is 
trivial but annoying.
4.  plane was recently patched to allow wrapping.  Thats fine but at the 
same time the non-compiz related function were changed from camel caps 
to underscore style.  eg.  endMove was changed to end_move.  I am not 
sure if these changes came from the plane developer or if they are 
trying to enforce some sort of coding convention.  None of the other 
plugins seem to have been subjected to this.  I really dont understand 
this part.

I would like to keep any patches on a third party site and preferably 
held in git (I personally use svn too but from what I understand git 
makes merging with other git trees easier).  I would love to have the 
help of the individual plugin developers which would make life easier 
for everyone, Erkin has been very helpful.

Maybe some sort of plugin developers amnesty would be good.  eg.  "I 
changed the compiz core for my plugin because....", they will not be 
judged or punished and David will help to get their requirements into 
core without unnecessary patches. :)

Anyway, back on topic.  It seems like there are plenty of changes which 
means blurfx will be much harder to port.  I have the gut feeling that 
the changes relate to shadows because the reflection and blurring looked 
strange when applied to the shadows.  They must have worked a way to 
separate the shadow region.  I will look into this more later.  My 
initial thought is that maybe shadows could be put into their own 
plugin, otherwise there will be duplication in the decorators and 
plugins like blurfx will only work with one decorator.


> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz