Jigish Gohil wrote:
On 10/5/06, Mike Dransfield <[EMAIL PROTECTED]> 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
_______________________________________________
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
