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.
> 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. I was merely continuing the thread with some ideas as they came into my head, enumerating various pros and cons as they came up, and pointing out some Pivot classes & functionality that others might not have been aware of. I am certainly not advocating a purely theoretical ActivityIndicatorDecorator as the best approach, just a *possible* approach. Chris > On Jun 17, 2011, at 4:46 AM, Chris Bartlett wrote: > > Yes, that is what I was thinking. > > Get the Bounds of the TreeBranch node that is being opened, > Create an ActivityIndicator (sized to match the node's Bounds height) > Add a 'AnimatedTagDecorator' (custom subclass to manage the > animation/repaint callback) to the TreeView using the nodes Bounds (+/- any > indents) to align the Tag > Set the ActivityIndicator as the Tag > Remove the decorator when the data loading task has completed > > To simplify for later use, much of the above could be encapsulated in a > 'BusyNodeDecorator' whose constructor would just take a Sequence.Tree.Path > as an argument along with a repaint refresh duration.. > > > Now that I have thought about it again, the ScrollPane should obviously > takes care of showing the correct region through its view port and the > TreeView should never need to know if it is wrapped in a ScrollPane or not. > That means that it should be enough to just place the ActivityIndicator > over the TreeView in the correct location the first time. > > But it gets complicated again when you consider that other TreeNodes might > be expanded, collapsed, added or removed while the ActivityIndicator is > showing, so the decorator would need to listen for those kind of events and > recalculate the bounds of the target node in order to keep the > ActivityIndicator aligned. > > > Perhaps this is all getting a bit too complicated? But the power of a > decorator is that it can be applied to any Component, meaning it could be > used in other scenarios. For instance it could be used to show an > ActivityIndicator at the end of a ListView while lazy loading more data > (triggered when the ScrollPane is scrolled to the bottom). > > > I might hack around with this idea later just to satisfy myself as to > whether if it would work. > It would be nice to be able to simply do something like > treeView.setNodeBusy(path, true) > and have the TreeView take care of everything discussed above. > > Chris > > On 17 June 2011 13:18, Edvin Syse <[email protected]> wrote: > >> Cool :) Should I attach the TagDecorator to the TreeView itself? >> >> Den 17.06.2011 00:19, skrev Chris Bartlett: >> >>> (Feel free to ignore all this - I am just thinking out loud) >>> >>> Maybe not so bad after all... >>> >>> >>> http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/effects/TagDecorator.html >>> You could extend a TagDecorator to include a callback to repaint itself >>> to ensure the animation occurs, and adjust the ActivityIndicator to >>> track the node's bound with the setXOffset() & setYOffset() methods. >>> >>> One downside would be that you would need to add a new decorator for >>> each node that is being loaded. Then you could open multiple nodes and >>> have multiple animations occurring at the same time. >>> >>> Chris >>> >>> On 17 June 2011 05:08, Edvin Syse <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Yeah, maybe this isn't worth it :) It's pretty sweet already :) >>> Thank you for the info. >>> >>> Den 17.06.2011 00:05, skrev Chris Bartlett: >>> >>> Thinking about it, I'm not sure how well something like this >>> would work >>> with a TreeView, due the fact that a TreeView is normally >>> wrapped in a >>> ScrollPane. >>> >>> You might be able to get the decorator to align to the correct >>> position >>> and then adjust to any ScrollPane movement. You certainly >>> wouldn't want >>> to just lock the ScrollPane in position as that would defeat the >>> point >>> of trying to keep the GUI feeling responsive. >>> >>> On 17 June 2011 04:56, Edvin Syse <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> >>> >>> Den 16.06.2011 23:53, skrev Chris Bartlett: >>> >>> No idea about the animated gif side of things but... >>> >>> I have a vague memory about a Decorator that overlays an >>> animated >>> ActivityIndicator over a Component. >>> >>> >>> Cool, I guess that could work :) will look into it! >>> >>> >>> >>> > >
