Am 19.11.2008, 20:02 Uhr, schrieb Christopher Barker <[EMAIL PROTECTED]>:
> Nitro wrote: > >> We will need to take a look how to generate good documentation for fc2 >> since some parts of it are generated on the fly, especially the "create" >> family of functions. Maybe I should type more informations into the >> docstrings for these cases. Or I'll generate the doc strings also at >> runtime if doxygen or some other tool is able to extract doc strings >> from a live program. > > hmm -- I don't think it can -- I wonder if any of them can. Anyway, I'd > suggest we go with a python doc tool, rather than Doxygen -- it's more > likely to work in this kind of situation. pydoc is fine, or Sphinx, if > we want it all to look nicer. Sorry, I didn't mean doxygen (used it too much during the last weeks and months :-)), I meant pydoc. IIRC I've heard of a tool which extracts those strings from a live program, but then maybe I am wrong. >> By default the bitmap is in front of everything, because it was added to >> the canvas first. > > shouldn't the stuff added first be at the bottom? I suppose it doesn't > matter much, as long as you know, but that's the usual convention. Changed in SVN, newly inserted objects are inserted 'front' now. > Marcos Duarte wrote: >>> nodes = self.canvas.hitTest(evt.wx_event.GetPosition()) > > this is a bit ugly -- why does wx_event have to be an atribute of the > event, rather than the same thing, with a few added attributes? Not a > big deal, I guess, but it kind of violates the "Law of Demeter". Also changed in the SVN version. The real solution is to get rid of wx_event here alltogether and make an fc event api which is independent of wx. So you can do e.g. evt.is_left_down instead of the current evt.LeftDown(). This allows using another gui package then wx to be used with fc, by only exchanging the renderer and the wx event handling in the fc.canvas.floatcanvas.FloatCanvas class while all other parts can remain the same. >>> is a bit quirky. An easier way would be >>> >>> print evt.coords >>> nodes = self.canvas.hitTest(evt.coords) > >>> Right now this is not implemented. I should probably think more about >>> a way >>> to tag coordinates with their respective coordinate system (like using >>> a >>> fc.Coords() class or adding a 'coordinateSytem' attribute to the >>> evt.coords >>> tuple). > > hmm I'm a bit skeptical -- I think the user should know what coordinate > system is being used. Yes, now there's evt.coords.world, evt.coords.screen, evt.coords.local. Other entry points in fc do not support this yet. It should be clear which coordinates should be used. By default everything is world coordinates except in a few places which want screen coordinates. These parameters are named screen_pnt and similar, so it should be clear in which coordinate system they reside. Of course the other solution is better, but that's going to be a lot of work. Maybe for fc3 ;-) > I guess one question is: what coordinate system should teh hit-testing > be done in? I think the current code does it in world, rather than pixel > coords. However, the user is seeing pixels, so it may be more accurate > to use pixel coords. In FC1, it's done tis way, relying on a offscreen > bitmap to do hot-testing -- this has other downsides, though. Hit-testing is always done in world space. Pixel space is maybe good for testing a single pixel against a bitmap, but fc2 uses hit-testing for more than just testing a point against an image. Nodes which are not in the camera's view are culled for example. This uses the same kind of hit-testing that picking does. It's more a spatial query than an image space hittest. The user might also want to hit-test a coordinate outside the current view region. Then pixel space does not seem sensible anymore. You'd want to specify the query in world space, then render the immediate area around this world space to a bitmap and finally translate the world space coordinate into a pixel coordinate in this bitmap. This is actually an easy way to make fc2 point hit-testing pixel accurate :-) Should be very easy to implement, maybe a dozen lines or so. You'd create a camera for this, render the canvas from this camera and then you'd do the steps I outlined. The viewport size of the camera would be so huge as 1 pixel in world space. If the bitmap was 1x1 you can save yourself the work of translating world to pixel-space and just read the single pixel from the bitmap and use this as the hit-test result :-) You'd even get nice sub-pixel interpolation for free... >> Yes, it would sound more intuitive if we could also get the global >> coordinates from an attribute of evt.coords. > > we need to clarify names of coordinate systems here... Yes. I call them world, local (always relative to some "parent" coordinate system) and screen. >> In fact, one thing I want to do is to apply my own spatial >> transformation (which I would calculate based on some points in the >> image) to the coordinates of the canvas. I don't need to do image >> calibration (I mean to change the image itself), I understand this is >> not the type of application fc was designed for > > I'm not entirely sure what you mean, but I think it should be able to > accomidate that. Yes, as long as the image can be distorted in a linear way. If you want to distort an image with a sine-wave for example, that's not going to work right now and probably never will. > > (also because my images are bitmaps not svgs). > > true -- but one can think of (and work with) bitmaps as scalable > graphics, too-a whole lot of rectangles! ANd I need to be able to work > with bitmaps too, so I hope we can get some of this to work out. Yup, one could do that, but it would be really really really slow for typically sized bitmaps. >> What I need is just the calibration (transformation) of the coordinates. >> So, in this scenario it would be great something like >> evt.coords.Global for the position at the global (screen) coordinate >> system; > > OK _- i don't see "global" as meaning "screen". I see these: > > "Global" or "World" -- the natural coordinates of your data > -- in the case of images, I guess that would be pixels of the image, > unless you are putting that image in another context. > > "Transformed" -- coordinates after the main transformation is applied. > The transformation is arbitrary, and can be non linear, but the > transformed coordinates should be transformable into rectilinear coords > (pixels) via an affine transform. In general, they will be rectilinear > as well. Note that "Transformed" coordinates are not exposed to fc2 users. Internally fc2 automatically separates linear and non-linear parts and takes the appropriate steps to render everything as intended. -Matthias _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
