Hi Thorsten, >>People who know what a pivot point is, and how to build an affine >>matrix, will not use XSimpleCanvas. On the other hand, people who will >>use XSimpleCanvas will probably be very happy with a simple >>"setRotation", since that's what they need (if at all). >> > Doesn't help. Rotation without being able to set the center of > rotation (that's what pivot point means here) is utterly useless.
Okay, then a semi-simpl "setRotation( degree, center )" :) I wonder how difficult it is for a non-mathematical API user to create an AffineMatrix2D from a degree and a center point. Please don't tell me this needs pen and paper, this would make the method completely useless to the average user (and thus I'd continue to argue it should be removed). If there were some service which creates such a matrix from a degree and a center point, then I'd vote for leaving the method in. As a compromise :), what about adding an /additional/ simplified "setRotation"? >>I strongly vote for not alienating the second class'es people by >>throwing "affine transformation", "pivot point", and other meaningless >>(sorry :) techno babble at them. > > I see your point, but I don't think we need dumbing down the interface > more than necessary. Transformations come almost for free on the > canvas (both simple and normal), and make things easy that have been > clumsy before. Every modern graphics API has them, people who need it > will (quite easily) learn about them, and the rest can simply leave > this method alone. You are argueing from the wrong side here, IMO. The fact that affine transformations can be implemented easily doesn't have anything to do with the question whether or not to slay the user of a XSimpleFoo API :) I conitnue to think that a majority of users (of this interface) will neither be able to easily set a rotation, nor have any other use for the setTransformation, so it's superfluous. >>Else, we should think about whom this whole interface should really serve. >> > > People who want to render simple stuff in user draw, I'd say. Those > will need rotation/scaling eventually, and it'd be a shame to have an > XSimpleCanvas2 just because of this missing expressiveness (or > exposing people to the full power of XCanvas, if they need > transformations). Which reminds me ... I don't know XCanvas and css.rendering in detail, but is it true that XSimpleCanvas, except simplifying the API, internally "only" holds the RenderState and the ViewState to be used for XCanvas' methods? If so, would it make sense to expose those two as attributes/methods? Else, the gap between using XSimpleCanvas and XSimpleCanvas::getCanvas would be pretty big, since a client which needs one small functionality of XCanvas is immediately forced to create own View/RenderStates, which need to account for everything else which he did so far with the XSimpleCanvas. Quite a steep learning curve, which could be eased by providing those two states. >>>(besides that one will need rendering of >>>XGraphic also on XCanvas, I guess). >> >>Why? Conversion could happen internally in drawGraphic, before it's >>passed to the XCanvas. >> > Sure. But what about the people using naked XCanvas? Should they > create an XSimpleCanvas, just because they need to render an XGraphic? > I call _that_ clumsy... Good point :) >>>Converting XGraphic to XBitmap is >>>lossy, in general (because XGraphic can also contain vector >>>images). >> >>That's okay - for the target audience of this interface, as I understand it. > > No, it's not. Just because an interface is simple/easy to use, it does > not mean it has to encourage wrong usage (please note that I'm really > thinking long-term here - a few years from now, scalable UI will be > prevalent, see Avalon/Aqua/increasingly cairo-based toolkits. I'm sure > you don't want ugly up-scaled bitmaps in OOo then...) I don't get your point here. Can XBitmap contain vector images? If not, then wouldn't it be better to use XGraphics, according to your argueing? /me is confused. > So, > clearly, an idiom like this should be achievable: > > mxRenderer.render( graphic ); > > or, if you retrieve the canvas dynamically: > > mxRenderer.render( graphic, canvas ); > > Looks concise enough to me. ;-) Sounds good to me :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
