You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@verizon.net> on 2011/07/15 20:27:39 UTC
Re: Accordion like Component that allows multiple open panels
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 <cb...@gmail.com> 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>
Re: Accordion like Component that allows multiple open panels
Posted by Chris Bartlett <cb...@gmail.com>.
Overdue switch to just the dev list (dev@pivot.apache.org) as it is
probably no longer appropriate for the user list
On 16 July 2011 02:06, Greg Brown <gk...@verizon.net> wrote:
>> 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.
>
> That's sort of what I was getting at. If it is nothing more than a glorified BoxPane, then there may not be too much value in keeping it.
>
> Not sure - just thinking out loud.
>
>
Re: Accordion like Component that allows multiple open panels
Posted by Chris Bartlett <cb...@gmail.com>.
I'll get the code tidied up into a small demo app and get it out
tomorrow. We can see where, if anywhere, this all leads.
I will also create a JIRA ticket for adding header/title rendering
functionality to Expander. That should be useful regardless of the
outcome of this.
I started thinking about events, and Expander has some broadly similar
events to Accordion, including vetos, so that side of things may mesh
without too much hassle.
On 16 July 2011 02:06, Greg Brown <gk...@verizon.net> wrote:
>> 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.
>
> That's sort of what I was getting at. If it is nothing more than a glorified BoxPane, then there may not be too much value in keeping it.
>
> Not sure - just thinking out loud.
>
>
Re: Accordion like Component that allows multiple open panels
Posted by Greg Brown <gk...@verizon.net>.
> 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.
That's sort of what I was getting at. If it is nothing more than a glorified BoxPane, then there may not be too much value in keeping it.
Not sure - just thinking out loud.
Re: Accordion like Component that allows multiple open panels
Posted by Greg Brown <gk...@verizon.net>.
> 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.
That's sort of what I was getting at. If it is nothing more than a glorified BoxPane, then there may not be too much value in keeping it.
Not sure - just thinking out loud.
Re: Accordion like Component that allows multiple open panels
Posted by Chris Bartlett <cb...@gmail.com>.
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 <gk...@verizon.net> 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 <cb...@gmail.com> 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>
>
>
Re: Accordion like Component that allows multiple open panels
Posted by Chris Bartlett <cb...@gmail.com>.
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 <gk...@verizon.net> 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 <cb...@gmail.com> 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>
>
>