This thread was long and somewhat confusing. For anyone following it, I have cleared up some issues to myself and perhaps others who find this thread.
My goal was to position arbitrary shapes at will upon the screen and then change thier location (but not shape). That's it. Here's what I concluded. 1) Some Shape (implementations) have this built in. Rectangle is one of those- it as a setLocation method. However, generally, there is no Shape (the interface) method for doing this, so you cannot define your methods to take a Shape and then reliably invoke any method, even if you cast to say Rectangle or Arc2D. This is because having no method defined in the interface, what location-mutation methods are to be had in the various implementations are all named differently and work differently, and also many Shape implementations don't even provide anything like a location-mutator, as is their right. 2) Despite there not being any promise of having a location to report or mutate, Shapes in fact DO live in an x-y coordinate space, called a user space, and they are definitively located in that user space. More precisely, by the a judgment of a winding rule, some x-y points are contained within a Shape and some are not; without this they wouldn't be a Shape. All of the methods defined in Shape - contains() intersects() getPathIterator() and getBounds() - all refer implicitly to their Shape's "location" (not to say ULHC) in user-space All these methods consider each point of the Path which makes up the boundary of the Shape to be a specific, definite point and will answer your question ( contains() intersects() ) or return some value (getBounds() getPathiterator() ) based on those points. 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? I chose to pile them all up in the same "place", by which I mean, their location, if they have one, is at user-space 0,0 and their getBounds has an ULHC of 0,0. Now if I drew them where they "think" they are, it would look like a bunch of Shapes piled up on top of each other in the ULHC of my screen. 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. 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. 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 done by translating the point by just the amount the Shape has been translated when it was drawn, and just before invoking Shape(implementation) contains(). To make getBoundingBox() and getPathIterator() behave as hoped, an AT should be applied to their result, again using the displacement the Shape was subject to when it was drawn. So here are some lessons, at lest for me- Shape and it's implementations are not like Components and neither are their bounding boxes. Some have methods to relocate themselves via setLocation() or setFrame()- but for your purposes- ignore these, they're red herrings. 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. They do, in fact, live at some definite place. This manifested by the points reported by their getBounds() and PathIterator(), both of which are implemented by Shape implementors. Yet these implementors are counted as Views, not Models. What the Model includes, oddly enough, is the offset at which the Shape is to be drawn- the place where it appears to the user and the place where it acts "as if" it is. That "place" we'll call it's location going forward. One possible implementation of this "place" (and not th most efficient perhaps) is an AT. We were advised to NOT let this AT be part of the Shape implementation- because the Shape implementation is the view and the AT is model-stuff. 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. It's not clear to me that the changing location is a model-point and the points of the path iterator are "view" points. That seems solidly backwards to me. Moreover, it just seems to me that Shapes are willy-nilly going to live SOMEWHERE, "we" might as well just fess up to the fact that not only are they located in space, but that space is going to be presented to the user on a device, probably, a screen. Because we have no, efficient, non- list-o'-points way to define Shapes, they have to be somewhere. Why not just accept that and provide a way to mutate that "somewhere" along with consistent contains() intersects() getBounds() and getPathIterator()? Anyway... I hope this clears up some things for someone. [Message sent by forum member 'swv' (swv)] http://forums.java.net/jive/thread.jspa?messageID=228374 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
