DIB Engine : passing all tests

[James McKenzie]

Massimo Del Fedele wrote:
> Alexandre Julliard ha scritto:
>>
>> The last time I rejected a simple patch from Massimo, he basically said
>> that he didn't have time to fix the patch and just dropped it. That
>> doesn't encourage me to spend more effort on reviewing his more complex
>> stuff.
>>
>
> Hi again :-)
>
> Well, to be precise those were some patches rejected, one with some
> explanation
> and others not.
> Former was about adding page size support to wineps.drv. I haven't
> dropped it,
> but you told me that an almost complete rewrite of cups printers
> handling was
> foreseen and preferred, so I kept it on my tree. I have really not
> enough skills
> nor time to do such a complex job. My patch was just sending the
> missing page size
> string to lpr along as printer name, which is by now the only stuff sent.
> I can understand, of course, that going through lpr is not a very nice
> way.
> I'm using the patch for my daily job, it's not dropped.
>
> Latters were one testcase (which was meant preparing some gdiplus
> patches....) which
> was rejected because "too long" and "with meaningless comments" and a
> couple of
> gdiplus functions that were missing (and are still missing) needed by
> autocad to
> run with builtin gdiplus, rejected because "contains errors"
> (possible, but which ?) and
> were "a pain to review" (hmmmm....).
> BTW, about comments, I'm sorry but my memory is not perfect and I tend
> to forget what I did
> and why after a couple of monthes, so the reason of maybe
> over-commenting all my code :-)
I tend to disagree with your self evaluation of 'too many'.  There is NO
such thing in coding.  I've seen code with too little comments and then
had to figure out what the heck the coder was trying to do inside the
code.  Of course, talking to the coder resulted in a "I know what I'm
doing" conversation that resulted in no forward movement on a fixable
problem that may have resulted in the company's demise.


> I must say that the must difficult part of writing my engine was to
> try to figure out what
> gdi32/winex11 code does, and some comments more woul have been of
> great help !
>
This is very true.  Code should at a minimum point out where the
examples can be found.  MSDN is very frustrating when it comes to how a
piece of code is supposed to work.

What I see here is a lack of assistance from those who grade the code. 
This is what I consider unacceptable and has resulted in the stoppage of
fixes being submitted by folks who 'code for food', that is they write
code for a living.  I evaluate and support programs for a living.  Guess
what?  I don't recommend that folks use Wine on Macs for production
level work.  It just is not 'there'.  Sadly, these same folks want to
walk away from using Microsoft Software because, pardon the phrase, it
just plain sucks.  It is poorly written and full of bugs (and some of
those bugs have been there for years.)  I appreciate AJs efforts to keep
the code base 'clean'.  In the process, however, you have to tell folks
what to do in order to keep the base clean.  That is just plain being
nice and is good ettiquitte.  Otherwise, all you are doing is attempting
to shoo away those who could really help move the project along and fix
long standing problems.  It does not take more time to state:  Your code
does not meet Wine standards because it has tabs in it", then to say
"You can do better".    Adding comments to what a certain chunk of code
does is not expensive and it does make troubleshooting code much easier
at a later time by a different person.  One line comments are best. 

So what say all, shall we try to make coding better and as Max stated,
fun.  Most of the folks here do not support this project for a living
and we should not restrict this project to those who do.  However, it
appears that a vast majority of the patches are coming from those who
either are long time Wine 'hackers' or those whose living depends on
this project's survival.

James McKenzie