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.
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. G On Jul 23, 2011, at 9:24 PM, Bill van Melle wrote: > The problem with tooltips is not their being confined to the window, but the > coordinates at which they are launched. > > I suspect I've gotten as far as I can get without editing the Pivot sources > (and as you saw, I did suggest an edit to the sources to get tooltip > placement). There are lots of controls I haven't even looked at yet, but I'm > guessing the main issue is that there are controls (such as ListButton) that > render stuff directly onto the window at the top of the display hierarchy, > with no knowledge of any transforms in between. I think to make them work > right with ScalePane, they would at a minimum have to do something in > addition to my (updated) mapPointToAncestor, say a computeScaleAtAncestor > method that walks up the tree and takes into account any scale transforms on > the containers it passes. And in order to make use of whatever numbers a > control got back from computeScaleAtAncestor it would have to have a way of > scaling the thing it's displaying. Which means either a ScalePane sort of > container, or a ScaleDecorator that (as Greg muses earlier in this thread) > the control's mouse events take into account. Is that too close to the extra > complexity that Greg suggested Pivot was trying to avoid by not having render > transforms at the component level? > >
