Il giorno ven, 09/09/2011 alle 12.42 -0400, Jamie Bliss ha scritto: > This might be considered off-topic, but this is the closest I could > think of. I need help trying to track down a bug. > > I have an application I'm working called cropper. (Screenshot: > <http://imgur.com/iIUCu> Source: > <https://github.com/astronouth7303/cropper>) It's basically a tool > that lets you crop an image in multiple ways at once. > > It's currently suffering from a number of major bugs, but the big one > that's really bothering me atm is zooming. > > The "workspace" is a single custom widget (ImageSpace, in > imagespace.py) wrapped in a ScrolledWindow. It has the ability to zoom > in and out on the content (by setting the zoom property, 1.0 is > normal, 2.0 is twice as big, 0.5 is half as big). The problem is that > when zoom != 1.0, it doesn't transform coordinates between the image > space and widget space correctly. > > For calculations and such, I define two methods (img2widgetcoords and > widget2imgcoords) for this transformation. (The image is always > centered in the widget.) But for drawing, I'm using cairo's > transformation methods. > > As far as I can tell, these two methods should produce the same > results. But somehow, something's wrong. It's exhibited when creating > new boxes, in the calculation cache system, and looking at output I > made specifically for debug (the spot that widget2imgcoords calls > (0,0) isn't where the upper-right corner of the image). > > Does anyone have any experience they can offer on this? Is this just a > disconnect between cairo's methods and mine? Am I just doing something > wrong? >
Hello Jamie, I just gave a very brief look at your code, and have a very brief suggestion: have you considered using directly Cairo matrix objects to manage coordinates changes? That's what I did - notice my problem was sligthly different from yours, and that code is probably in non-working state - for instance here: git clone git://pietrobattiston.it/spilla (if I remember correctly, for instance "transform_point" used in spillamod/operations.py) and it was very useful - I can always make drawing bugs, but once I draw, I know clicks are in sync with the drawing. > Thank you, You're welcome, good luck! Pietro _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
