> > Your TerraAccordionSkin might override these so that the header is a simply > a real BoxPane with an ActivityIndicator and a Label inside. Then the > BoxPane skin (and ActivityIndicator & Label skins) will take care of > painting, and more importantly, animating. > (ie, use real, fully fledged Components, rather than a Renderer for each > header) >
Yes ! that sounds good, seems elegant and efficient. I will look into this solution Thank you very much Simon On Mon, Mar 21, 2011 at 4:07 PM, Chris Bartlett <[email protected]>wrote: > Another thought might be to ditch the renderer approach entirely and to > create a custom subclass of Accordion along with a custom skin extending > org.apache.pivot.wtk.skin.terra.TerraAccordionSkin. > (Or just copy both classes and edit to create your own parallel versions > rather than extending) > I haven't prototyped it, but I think it (or something similar) should work, > although I'm not sure it is necessarily preferable to just managing the > repaint callbacks yourself. > > TerraAccordionSkin contains these 2 inner classes which deal with the > Accordion headers and will normally use a supplied renderer to render the > header. > org.apache.pivot.wtk.skin.terra.TerraAccordionSkin.PanelHeader > org.apache.pivot.wtk.skin.terra.TerraAccordionSkin.PanelHeaderSkin > > Your TerraAccordionSkin might override these so that the header is a simply > a real BoxPane with an ActivityIndicator and a Label inside. Then the > BoxPane skin (and ActivityIndicator & Label skins) will take care of > painting, and more importantly, animating. > (ie, use real, fully fledged Components, rather than a Renderer for each > header) > > For more flexibility you might expose the BoxPane used for each header so > that you can set its content, properties and styles as required. > > Chris >
