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.
> 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.
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".
>> 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.
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.
> 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...
> 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.
> (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.
> 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.
"Local" -- coordinates local to a given object -- I think these are an
affine transform from "Transformed" coords. This would be the transform
applied to only that object.
"Pixel" or "Screen" -- the actual pixel coords when drawn on the screen.
-- this is the final result when you start with world coords, and apply
all the transformations.
"Paper" -- coordinates if the iamge was printed -- this would relate to
pixel coords by a resolution parameter -- PPI or whatever. This would
allow folks to specify thinks like line widths and fotn sizes in points
(or inches, or mm, or ...) and also specify a scale, which would map
transformed coordinates to paper coords. The resolution would determine
sizes of things in screen coords.
Does this work with how FC2 is now constructed? I think it has
everything but the "paper" coords concept.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
_______________________________________________
FloatCanvas mailing list
[email protected]
http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
