On 9/9/11 3:28 AM, Pierre Ossman wrote: > Chill. Saying that people cannot do any changes without first getting > your seal of approval and/or spending hours of testing even for small > changes is not a constructive way to encourage development on this > project.
With respect to the Tight encoder, I am not trying to encourage development. It's a somewhat fragile piece of code that took a lot of time and domain expertise to get right. I don't want to change it unless there is a good reason to, such as a build problem or a new feature addition. > The reason those variables are now dynamic is to avoid having to > include jpeglib.h in any other place than JpegCompressor.cxx. We cannot > have undefined structures as part of the class definition in that case, > but pointers to undefined structures is okay. > > The reason we want to avoid jpeglib.h as much as possible is for things > like this: > > typedef long INT32; > typedef int boolean; > > Such generic typedefs have a very high probability of causing > conflicts, and they do in practice with mingw. Including such information in the commit message or sending a quick note to the list following the commit would head off a lot of this misunderstanding. I accept your reasoning, but I now need to stare at the code for a bit to make sure there are no side effects to using dynamic allocation. ------------------------------------------------------------------------------ Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
