[compiz] Zoom plugin changes

[Mike Dransfield]

Kristian Lyngstøl wrote:
> I'm sorry for being rude, but I am quite upset by this, because it has
> gone too far.
>
> I posted a few weeks ago that I was going to be working on zoom over
> the summer to improve the accessibility, and I have already begun to
> do that. Every step of the way I have made frequent commits to
> opencompositing.org and described the progress in my blog.
>
> I asked for information about what your (David) plans was, you thanked
> me for informing me on what I was going to work on and said you'd get
> back to me. You never did.
>
> Now today you commit "11fe37b7673b15e5cbd4be21759311087d9d8694" which
> introduce major changes to the zoom plugin. You did NOT give a heads
> up on this, even though you should have known I was working on this.
>   

To be fair he did mention that he was going to add
this functionality months ago, it was also demonstrated
at brainshare recently (before your initial email).

Also your email (from what I understand) just related to
orca integration and input redirection, it didn't seem to have
anything to do with todays changes.

Also from what I understand, you have forked zoom.c which
lost all the git history?  If this is the case then you should
have branched it so that these changes would be merged. I
dont think they impact your changes, do they?

> This is simply unacceptable.
>
> When you are going to make changes and people have already told you
> they are working on that code, you have to actually communicate with
> them, not drop a 1k diff on them. It's not just your time that matters
> here, but ours too. This is not how people are supposed to co-operate.
>
> And also, when you write something, you have to document it.
>   

The question of documentation was discussed very recently
(and before that too).

Davids position is that HE is not prepared to spend a lot of time
documenting things because there is a good chance his
efforts will be wasted if the code changes, personally I'd rather
he spent time coding rather than documenting.  Someone else
could document things.

That does not stop anyone from submitting patches to document
certain functions which might not be clear.  I did exactly that a
few weeks ago.

> A few lines for each function, explaining what it does. You don't have
> to explain how or why, just WHAT. This is a common practice that I
> should NOT have to explain to an experience developer.
>   

Its not common developer practice to document each
function.  Most people do not seem to have much problem
understanding whats what, and David is always prepared
to answer questions.  The documentation is by example at
the moment, I have 3 example plugins, the helloworld one
is documented as well as I can, and I try to keep it up to
date.

> Please document your changes to the zoom plugin properly so our USERS
> don't have to choose between two different feature sets when they want
> to zoom. Because this is about the users, not my pride.
>   

If you understood the original zoom code enough to
make an enhanced version of it then it should be easy
to understand the new changes, they seem to be reducing
code and increasing readability to my untrained eyes.