compiz - Oct 2006 - BlurFX for compiz

Here is my quick patch to blurfx and compiz, there are a few changes to 
core and the end result isnt exactly bug free.  I get lots of artifacts 
left all over the screen and parts of the screen being left blured.  I 
am not sure if the problems are deep in blurfx or if it is just me.

It has an old schema file in there which works for blurring transparent 
windows but not for the decoration, I assume this is related to the cgwd 
changes.  Hopefully someone can use gconf-dump to get the schema back 
out.  Ill wait before attempting to do it manually again :)

The changes in screen.c and compiz.h and decoration.c seem reasonable 
(except the things already discussed for the animation plugin).  Maybe 
they could be included in the main tree?

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 am also looking at pulling out some of the patches from beryl.  Some 
of them seem useful, I think if they were individually pulled out then 
David can decide on a case-by-case basis.  At least there could be some 
sort of communication between the forks.  Is this worth looking into?

Download from here

http://www.anykeysoftware.co.uk/compiz/blurfx-for-compiz.tar.gz

On 10/5/06, Mike Dransfield <mike@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.

Jigish Gohil wrote:
> On 10/5/06, Mike Dransfield <mike@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz