Unlike some other things I have suggested over the last few weeks, this is not something that I have strong feelings for. The thread just started from me wondering about the similarities between Accordions, Expanders (and Rollups) and how to show multiple open 'panels' simultaneously. I am happy to post my 'solution' for a fake Accordion (or submit as a patch etc) once it has been tidied up, and if it is wanted, but I won't be pushing for its inclusion over a regular Accordion.
After only about an hour playing around from start to finish, it is obviously a little rough around the edges at the moment, but that is mainly because TerraExpanderSkin isn't sublcass friendly. However, if that was taken care of and if Pivot's Expanders were to be given HeaderDataRenderer support similar to an Accordion's, then it wouldn't take much for any developer to build a convincing, but fake, Accordion out of Expanders. That would give developers full control over the selection policy of the 'fake Accordion', so it could be used as a workaround for https://issues.apache.org/jira/browse/PIVOT-572, as well as my problem which was multiple open panels. I suppose that if the fake one is easy to build and able to provide more flexibility than the real one, then perhaps the real one really isn't required in its current form? (No idea if that is the case yet). The actual org.apache.pivot.wtk.Accordion class could still remain, but its functionality could just be replaced by the relevant part of this technique of stacking Expanders. So it would pretty much just become a glorified vertical BoxPane containing Expanders. Chris On 16 July 2011 01:27, Greg Brown <[email protected]> wrote: > I think this is really cool. My only question is - how useful do developers > consider the existing accordion behavior (only one panel open at a time)? If > there are still use cases for it, then it probably makes sense to retain as > its own component. If not, then it could probably be dropped. > > But more to the point - if there aren't significant use cases for Accordion, > then is it really worth creating an ExpanderGroup class to emulate this > behavior? I don't know since I'm not the one driving this. :-) Just > thinking out loud. > > On Jul 15, 2011, at 2:08 PM, Chris Bartlett wrote: > >> On 15 July 2011 23:39, Chris Bartlett <[email protected]> wrote: >>> I suppose it could go the other way too. >>> >>> Create ExpanderGroup as an equivalent of a ButtonGroup, and just use >>> that to manage 0 or more Expanders. >>> If you want an Accordion like effect, you would stack multiple >>> Expanders together and add them to the same ExpanderGroup. >>> >>> That would be far simpler. >> I just knocked up a prototype of this, and it seems to work fine in >> the most simple scenario where all expanders are expandable. >> I subclassed Expander & TerraExpanderSkin classes to be able to change >> the mouse click behaviour, and hack in some pseudo ExpanderGroup >> functionality. >> >> Single left click will open/close the clicked expander and close any >> other open expanders >> Single left click + SHIFT will open/close the clicked expander without >> changing the state of any other expander. >> This allows 0 or more expanders to be expanded at any time, but could >> easily be changed to ensure that at least 1 expander stayed open to >> more closely resemble a traditional Accordion. >> >>> The only thing I can think of that would be needed with this approach >>> is some sort of HeaderDataRender mechanism to allow the header of an >>> Expander to be rendered as the user desires. >> Having the renderer would give me all the freedom I need to get rid of >> the expand/collapse button (arrow). >> >> Apart from that button, the only noticeable visual difference between >> the fake Accordion and the real one is that there is an extra line >> painted between vertically stacked Expanders. >> See the attached screenshot (fake Accordion on the left, real >> Accordion on the right). >> That should be simple enough to fix though. >> >> It certainly suggests that dumping one of Expander or Accordion should >> be possible, with the retained component filling in for its sacrificed >> comrade! >> >> I can post the code tomorrow if anyone is interested. >> >> Chris >> <ExpanderPanelZoomed.png> > >
