Hi Noel, Great feedback. My comments below.
>- what's with the naming of ComponentClassListener? shouldn't that be >FocusListener? It's not necessarily limited to focus events - that's just the only one in there right now. >- and shouldn't the static field Component#componentClassListeners live >on instances of the Window object? > Focussing is a per-window thing. In Pivot, it's global. However, each window tracks its most recently focused component so it can restore focus to that component when it becomes active. >- nothing seems to be adding to Component#components. I'll look into this. It may no longer be necessary. > I think Component#components it is there to allow runtime theme changes??? > A much lighter-weight approach would be to track the current Window >objects, and then run down the containment hierarchy. I believe that's what we do now. I'll confirm. >- Component#focusedComponent should be a field of Window, since each >Window can have it's own focussed widget. See above. >- Component#decorators should probably live inside >Component.DecoratorSequence This could go either way. We have a few cases like this in the code. >- Component#handle seems to be only useful for debugging Yeah, this could probably be eliminated. >- Component#preferredSize is a cached value - why is it necessary to >cache this value? Is it expensive to retrieve? It can be. >- Component#userData is going to be hard to use. > It is very handy to be able to stash extra info on a component, but >when multiple libraries all want to do this, it quickly gets out of hand. True. We've talked about eliminating it in the past, but there are valid use cases for it. Also, other toolkits include a similar feature. So there's probably no real harm in including it. G
