> On 17 June 2011 19:36, Greg Brown <[email protected]> wrote: > Keep in mind that decorators don't automatically repaint themselves. If you > stick an ActivityIndicator in a decorator, it won't animate. The decorator > will be responsible for calling repaint() on the TreeView as needed. > Yep, I mentioned that I couple of times in the thread.
OK, sorry. Guess I didn't read carefully enough. > > Why not just do this in the node renderer itself? You'll need to call > repaint() on the tree view either way, and the node renderer is already > painted at the right place (unlike a decorator, which will need to figure out > node bounds, deal with scrolling, etc.). > Using the node renderer is certainly an option, but as mentioned in the > previous email, the decorator approach is easily adapted for other scenarios, > such as the hypothetical ListItem one. I haven't implemented this, so there > may well be some show stopper that I am overlooking. > > The iTunes search demo uses a StackPane to overlay an animated > ActivityIndicator over the search results. With an > 'ActivityIndicatorDecorator' this could be achieved over any Component and > without the need for the StackPane. It could also be placed at any arbitrary > position over the target Component rather than just being restricted to > wherever that Component's Renderers paint. The advantage of using StackPane here is that the caller does not need to worry about repaints. It also ensures that mouse input to the underlying UI is blocked, similar to how the "glass pane" can be used in Swing apps. G
