>> For what it's worth, WPF has transforms built in at the component level, so >> this kind of thing is much more doable, but I'm sure people here are sick of >> my bringing up WPF. >> > No, that's fine, it's always nice to know what the competition is capable of. > Like you say, WPF has baked this in at a more basic level, which is what I > think that this feature would require.
The main challenge with this is that it complicates layout. Right now, we ask a component how big it wants to be, and the container decides where to put it and how much space it will get. If we supported transforms, the container would also need to be concerned not only with how big the component wants to be, but where it wants to be after transforms have been applied. That's why we took the decorator approach. Decorators allow you to apply a transform, but the component's bounds stay as-is. Just thinking out loud now - if Component took the decorators' transforms into account when processing mouse events, a scroll pane might work. Not sure. > Personally, I think you're just better off make your widgets scale nicely to > the available space in the first place. > I do that for all of mine. In general I agree with this. Though as I recall, WPF does have a "scale pane" (can't remember what it is called), so it would be nice to say that Pivot *could* do the same thing if desired. >> If you want a challenge, and you want to improve the Pivot state of the art >> in layout, Apple's new AutoLayout feature >> has some nice ideas: >> http://developer.apple.com/library/mac/#releasenotes/UserExperience/RNAutomaticLayout/_index.html >> >> At first blush, it seems like much of what people would use their >> complicated constraint language to do is already pretty easy (and more >> understandable) in WPF and Pivot. Maybe I'm missing something. > It's nice because it encodes the constraints at a more human level, and it > has nice failure modes when the constraints are unsatisfiable. > Our stuff is pretty good, but its always interesting to see what other > approaches have to offer. My first reaction was similar to Bill's, but I'd like to read the doc again more closely since there are probably some good ideas in there. G
