[patch] cosmetic fix for KPlotWidget

[Zack Rusin]

On Saturday 01 December 2007 01:25:14 pm Jason Harris wrote:
> The idea behind KPlotWidget is that people don't need to think about
> the widget's pixel-based coordinate system at all, they can just use
> their data's natural units and the code takes care of translating it
> to the screen.  So I don't think that shifting the entire coordinate
> system by (0.5, 0.5) is a problem at all.  We've already applied
> translate( xpadding, ypadding ), where xpadding and ypadding are
> lengths determined by the code to provide enough room outside the plot
> axes for showing tick labels and axis labels.  I can't imagine a case
> where anyone would care whether the computer picked PAD or PAD+0.5 for
> these lengths (where PAD is typically a few tens of pixels).

That's not really what I meant. What I meant is that shift by 0.5 happens to 
shift coordinate system in a way that with the identity matrix makes integer 
based horizontal/vertical lines align with the pixel grid a lot better. This 
doesn't mean that all the primitives (especially ones with many diagonals) 
will align in the same way. 
Plus like I mentioned the shift will in the best case be useless and in the 
worst produce worse results if the users will decide to draw a scaled plot 
(widgets on qgraphicsview will be a good usecase here, because 0.5 can mean 
shift by any arbitrary screen length then [from infinity to zero, altough 
that could be fixed with some clever matrix multiplication])
But I'm not arguing for anything, especially that I don't have time to 
actually hack on it, so I think you should do whatever makes you comfortable, 
I just wanted to point out some technical aspects of it =)

z