On Mon, Jul 25, 2011 at 4:58 AM, Greg Brown <[email protected]> wrote:
> I think the key to managing the complexity is ensuring that transforms are > visual only. In other words, painting and user input processing would take > them into account, but layout would not. > That would limit complexity, but I think it would also be the more confusing path for the user. The simple user model for a ScaleDecorator is "I want to make this component twice as big" with the implicit expectation "therefore it should consume twice as much space". This was actually something that threw me for a while in WPF, where at the component level you have both a RenderTransform, which I think is what you're proposing, and a LayoutTransform, which takes the transform into account when laying out a container. Before I well understood the difference, I had set a RenderTransform on something I was laying out, and it took some while before I discovered LayoutTransform was what I really wanted. (I think that RenderTransform exists as an optimization, so that you can use it on controls that don't need to be laid out, such as controls placed absolutely on a Canvas.) Of course, even Decorators as they are now, with no mouse transformations, have this potential for user confusion, so I guess you wouldn't be any worse off. Since decorators already have an associated transform as well as the ability > to scale a graphics context, I thought that might be a good place to start. > Container would need to be modified to respect the concatenated transform of > a component's decorator sequence when processing mouse input, and probably > mapPointToAncestor() as well. > Seems reasonable. It might make my ScalePane implementation slightly simpler (I could take out the mouse and paint overrides and just use a ScaleDecorator to get the desired fit), and it would certainly make all the Decorators that use a transform more versatile.
