That sounds like a plan :) I'm off to martial arts camp for the weekend,
so no more Pivot play for me unfortunately :(
Let me know if you do something with this? :)
-- Edvin
Den 17.06.2011 10:46, skrev Chris Bartlett:
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]
<mailto:[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]>
<mailto:[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]>>
<mailto:[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!