<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
But... hmm... the test like they are now will not compile and I'm
afraid they never will :-/<br>
The changes I've done to the interface weren't done accidentally but
by purpose.<br>
It wouldn't be right/possible to fit the new KisCoordinatesConverter
class to the old class interface.<br>
I just fixed up the tests. They should compile now but won't pass.<br>
I only can change the tests so that they will pass (they will
definitively not pass in the current state).</div></blockquote><div><br>Well, if some tests fail, it means that some other subsystem may fail because of changed guarantees. I think you need to write what coordinate systems you have now and how your QTransform objects reflect relations between these coordinate systems.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im">
</div>
I should have renamed m_postprocessingTransform because it really
has a different purpose then before.<br>
But I'm really sorry. I tried out other versions before and came to
the conclusion that there is IMHO no other<br>
way of doing it.<br>
I think you know that matrix multiplication is not cumulative so it
won't work (or just works to<br>
a certain limit) to have rotation, scaling and translation in
separate matrices, when you need to track the relative<br>
change of one coordinate system, and then multiply them together in
the end. </div></blockquote><div><br>I'm sorry, but i didn't get what you mean. And Cyrille either. As far as i know, the more multiplications you do on a single matrix, the less precise it becomes. I think we can discuss it on irc or skype.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>For further work i need that the krita canvas is able to
rotate, zoom and mirror the image around an arbitrary point and this
flexibility only comes with the code above.<br></div></blockquote><div><br>In the initial approach, all these types of actions were intended to be done during Flake -> Postprocessed Flake coordinate system conversion. The only flaw here was that during rotation around arbitrary point, you would have to change scrolling values, so you would have to change Postprocessed Flake->Widget conversion as well. Is that the problem you meant? <br>
<br>But, now, as far as i can see from the patch, you calculate "documentOffset" value indirectly after the transform is done and then just asks KoCanvasController to reset scrollbars with pan(). [1] Do i understand it right? If so, there is still no reason in keeping postprocessing transformations in the same matrix with document offset. <br>
<br><br>We can discuss it on irc, to make the things faster.<br><br>[1] - btw, i wonder whether setDocumentOffset() will be called right after updateOffsetAfterTransform(). Will it?<br></div><br></div><br>-- <br>Dmitry Kazakov<br>