[patch] cosmetic fix for KPlotWidget
faure at kde.org
Mon Dec 24 13:49:56 GMT 2007
On Tuesday 04 December 2007, Zack Rusin wrote:
> so lets try this again, but this time with the attached
> example. the example illustrates:
> a) how to properly snap primitives (within the DRAW_GOOD_SNAPPING) - of course
> as i repeated a few times - this is vector graphics no amount of snapping
> will solve all the cases but this one is the closest,
> b) how not to snap, which is what was committed (within the
> c) why "b" is wrong and how it breaks (within the MESS_UP_SNAPPING)
> d) that the coordinate systems do match, it's just that the the aliased one
> rounds up towards ceil (with SHOW_WHERE_ALIASED_COORDINATES_START)
> i think this should answer almost all the questions posed in this thread. what
> it doesn't answer is why it was done this way but life has its mysteries and
> the sooner we learn to deal with them the better.
Thanks for this example.
To understand it better I made it interactive, so that one can now toggle
checkboxes and see the effect immediately, rather than modify code+compile+run+open png file :)
New example attached, I hope this helps others understanding it as well.
I see your point about scaling messing up the "bad snapping", of course.
However I was looking for a way to fix a similar snapping problem, and if
one -knows- that the painter isn't transformed (okay maybe not in KPlotWidget, but in other cases
like widget styles or custom widgets), and that the drawing is done in integer coordinates only,
then the translate(0.5,0.5) appears to be a working solution :). But only in those cases of course.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4021 bytes
Desc: not available
More information about the kde-core-devel