I wanted to clarify some points here...
[EMAIL PROTECTED] wrote:
[Points 1 and 2 omitted - all true]
3) Remembering that the goal as to shuffle these around the screen, and having
them at definite places which are not so easily mutated, what's a developer to
do?
Generally if a bunch of arbitrary shapes are to be manipulated, a
"model/view" system is constructed which manages mapping between the
coordinate space of the shape and the coordinate space of the view.
In order to draw them where I want them, it's a matter of remembering where they wer
drawn last, getting the Graphics into device space 0,0 (which coincides with user-space
0, 0 ) and now that device and user spaces are in agreement, using one of the methods of
graphics to relocate where the "tip" of the graphics pen is located and hence
where it will draw. IF I want the Shape to be at 100,500, then I relocate the graphics
there and so on.
That is the beginnings of a model/view system. Your terminology is
confusing, I would say that one should "translate the coordinate system
of the graphics so that 0,0 in user space refers to the appropriate
location of the object in the original coordinate system".
I'm not sure why you refer to "the tip of the pen" since the Graphics
object doesn't have a pen that has a location per se. It does have an
attribute that defines how to stroke paths, and the default
implementation of that attribute (the BasicStroke) does operate as if it
were dragging a "pen" along the shape, but that "pen" is relative to the
path being drawn, it doesn't have an independent concept of "its location".
Also note that I said "original coordinate system" above, rather than
"device coordinate system" because when the paint() method is called (or
the Swing paintComponent() method), there may be some translation or
scaling that was applied by the system which means that the default
coordinate system when you start the paint() method is not "device
space". At the very least, the 0,0 origin of the incoming graphics
object points to the upper left corner of your component, but your
component is likely not located at 0,0 on the screen, or even at 0,0 on
the window it is on. Going beyond that, if you are printing then the
scale factor may not be 1:1 when the method is called to generate output
for the printer. Perhaps "Component coordinate system" would be a
better term there.
Now my shapes appear where I want them. But their other methods, contains()
intersects() et.al. are all liars, or at least, out of sync with where the
Shape has been drawn.
I wouldn't call them "liars". Those methods are defined relative to the
coordinate space in which they are drawn. If you draw them in a
modified coordinate space, then you need to perform hit testing relative
to that coordinate space as well.
To bring these other methods into line, you have to, in the case of intersects
and contains, first displace the point you're asking about so that it is
relocated back into that ULHC where all the Shapes think they live, piled up
one on top of the other.
This is where a good model/view system comes into play. Not only does
it manage modifying the coordinate system on the Graphics during
rendering operations, it should also provide mechanisms to modify
coordinates being hit tested so that they are relative to the same
coordinate system in which the object is rendered within the view.
By my measure, Shape and its implementations have a built in contradiction with
respect to the separation between Model and View, which could be a source of
confusion.
I think it is better to consider that all of their methods are defined
within a single consistent coordinate system. If your model/view system
translates the graphics to render them at a specific location and
orientation, then it needs to also perform equivalent transformations on
any other coordinates that are compared or executed against any other
Shape methods.
In this manner I consider the Shape interface to be Model and View
agnostic. It doesn't provide any mechanisms to adjust for either a
Model transform or a View transform. It is your Model/View architecture
which must maintain consistency in its interactions with the Shape
interface.
Beyond that, all is left up to your model/view implementation so the
ensuing paragraphs about how the Shape agrees or conflicts with either
the "Model" or the "View" concept are really just the fact that such
concepts are beyond the scope of the Shape interface as I have described
above.
But that AT, at least this is how it seems to me , is more View than anything
else, while the Shape itself, which is to say the Model, lives unchanging
elsewhere.
Again, I consider the AT to be a tool. Model and View architectures are
free to use that tool to implement their own concepts and designs, but
the AT is not a View and it is not a Model, it is just a 6 element
affine transformation.
Because we have no, efficient, non- list-o'-points w
