Re: [compiz] Zoom plugin changes
On 5/31/07, Mike Dransfield [EMAIL PROTECTED] wrote: Kristian Lyngstøl wrote: 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. I asked for an explanation of the features David wanted. He said he would get back to me. He didn't. Then he drops a big diff. My work will use at-spi but there were other important things to consider too. The diff is pretty much a total rewrite of the original which I have based my work on. 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? My point here is twofold: 1. I informed that I would work on zoom and requested information on it. David confirmed, and posted that he would get back to me. 2. Our users now have to choose between two different feature sets. As for if it should be a branch or not; maybe so. I'll have no problems re-playing my diffs to retain the history. I'm prepared to do that extra work, as it's my own folly for not keeping the history. This is sort of beside the point here. 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. It takes little to no time to document your own code, but it takes a lot of time to document someone else's code. It is the individual developers responsibility to document their OWN code. This helps the community at large because if you spend 1% of your time documenting, the time save in the other end is huge. By not documenting the code, it forces other people to reverse engineer his code when they want to work on it. A few comments on each function is the difference between using 15 minutes to understand the code, and an HOUR and 15 minutes. And then you multiply by the number of readers. 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. Should not be necessary. It does not take a lot of time to document your own code, and it is a sign of a good programmer. I know projects that will just say sorry, try again. if you attempt to submit undocumented code. Not documenting your code is two things, whether that is the intent or not: - Lazy. - A slap in the face of the other developers. 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. ... Your help plugins are a great help for new Compiz developers and all though I have not used your work on them myself (By the time you wrote them, I didn't need them), I am grateful for the work you've put into them. However, this doesn't void the need for documenting the rest of the code. And it does not help me at all. And I doubt most people know up from down in half of the code David has written. Sure, you can read the individual parts, but to trace the flow of the code, to know how it all fits together, that requires more than just reading each code file line by
Re: [compiz] Zoom plugin changes
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. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Zoom plugin changes
On Thu, 2007-05-31 at 02:19 +0200, 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. 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. 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. 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. I never intended my zoom plugin to be the zoom plugin. It's just a zoom plugin that implements some zoom functionality. I hope that people haven't been under the impression that any zoom functionality that could be written would have to go into my zoom plugin. That's definitely not what I'd like to see. I'd like to see different zoom plugins that implement different zoom functionality. There's no reason the user should have to choose between them, they should be able to use them all at the same time if they want that. I always though that my zoom plugin was useless and more for demo purposes. I wrote a more useful zoom plugin a while ago and I though it made sense to replace the existing zoom plugin with this one, which is what I did yesterday. If someone found the old functionality useful or if you've been able to build something useful from it then I'm happy to see it available as an additional zoom plugin. The things I wanted to get back to you on related to the zoom work you do has very little to do with the implementation of zoom plugins and more to do with how other changes are important to make zoom functionality useful. E.g. changes I'd like to make to the core which will allow applications to incrementally move towards using resolution independent retained mode rendering etc. but I have unfortunately not had time to do that yet. You can ignore my recent changes to the zoom plugin in the fdo repo and keep working on your zoom plugin. I don't want my changes to cause you any unnecessary pain and I'm sorry if they got you upset. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Zoom plugin changes
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. 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. 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. 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. -- Regards, Kristian ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
