pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: Activity Indicator in accordion header
Date Mon, 21 Mar 2011 14:28:31 GMT

I'll try to have a look at your code and send another reply later.

On 21 March 2011 20:28, Simon Chatelain <schatela@gmail.com> wrote:

> In fact I tried different approaches: first I had a timer calling
> Accordion.setHeaderData() each time with a different icon, and that didn't
> work even if setting the header data will definitely invalidate the header's
> area, will it not ?  In this case the behavior was the same as with the
> ActivityIndicator : refresh only when moving the mouse on the Accordion.

I'm no expert on the layout and painting side of things in Pivot, so
wouldn't be able to comment with any authority unless I started digging
around in the code and experimenting.  Unfortunately I don't have time to do
that right now, so perhaps someone else can help out with this?  Perhaps
repainting is the key and I was wrong about the invalidating?


Invalidating a Component layout related, so if you just need to repaint,
calling it should not be necessary.  However I think that invalidating a
Component *might* cause a repaint depending on circumstance.

Then I tried to setup a ScheduledCallback directly in my
> AnimatedHeaderRenderer to invalidate the ActivityIndicator (by calling
> invalidate()), still the same behavior, and finally I set up a
> ScheduledCallback in my application, invalidating the Accordion itself but
> still no luck.

The ActivityIndicator that is embedded into your renderer should be fine and
should not require any repainting/invalidating/whatever.  Remember that a
Pivot renderer is often shared and used to paint multiple components. Any
Components which might be used by the renderer during the painting process
are non-functional (won't respond to focus requests, keypresses, mouseclicks
etc).  The resulting image on the screen is ultimately just that - an image,
albeit one that was drawn by a fully fledged Component.

If you want this image to be animated, you will need the renderer to 'rubber
stamp' the target area repeatedly so that it can repaint.  If
the ActivityIndicator used by the renderer is active (it is animating
itself) then subsequent repaints that use the renderer should also animate
(unless they are exactly in sync with the underlying ActivityIndicator).

I think you need some sort of callback that repaints the Accordion's header,
using your custom renderer.

But if I call myAccordion.repaint() instead of myAccordion.invalidate(),it
> works. But I really don't like this solution because it means that I need
> not only the AnimatedHeaderRenderer but also a ScheduledCallback at the
> level of the class containing the Accordion using the custom renderer.
Is that really a problem?  You could probably subclass Accordion and bundle
all of the logic together to hide the implementation details.

Can you explain how you intend to use these animations?  It might help me to
understand and then (hopefully) suggest some alternatives.

Your initial example code showed multiple accordion headers with activity
indicators.  Are you using the activity indicators just when loading content
for the accordion's panels?  ie, Will the ActivityIndicator always be
running, or will it need to start & stop (possibly multiple times) at some

Will *all* of the ActivityIndicators be active/inactive at the same time, or
individually for each Accordion header?

> snip...
I'll try to look at this later...

I don't understand either why parent and ancestor of the
> AnimatedHeaderRenderer  are always null.
Search for 'renderer' on this page.

Although the AccordionHeaderDataRenderer is actually a subclassed BoxPane,
it is not attached to the Display like other Components.  Because it is not
attached to the Display, or another Container, it's parent will always be
null.  As it *is* a BoxPane it *could* be added to the Display, but that
would not achieve anything useful.

The Accordion(s) which use a AccordionHeaderDataRenderer merely use its
layout and painting capabilities to paint an area of the screen.  Renderers
do not need to be subclasses of Pivot Components or Containers.  They could
just as easily paint directly onto the Graphics2D object.

(Note the interfaces which Renderer itself implements)

What am I missing ? Do you have any idea about what to do to make it work
> from inside the AnimatedHeaderRenderer  class ?
The renderers provided with Pivot are designed to be flexible and for use
rendering content in many Components at the same time.

When you call Accordion#setHeaderDataRenderer(Button.DataRenderer), the
AccordionHeaderDataRenderer does not know that it will being used to render
content for that specific Accordion.  However when it is actually used, its
render() method is passed a reference to the target Button.

If you want to be able to set an AnimatedHeaderRenderer for an Accordion and
have it manage the callbacks required to repaint, then it will need to
contain more logic.  I won't go into details now until I better understand
your use case, but it should be possible.


View raw message