pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Pivot event handling
Date Tue, 08 Jun 2010 17:46:00 GMT
Extending the default list view skin is certainly one solution. However, I actually don't see
a problem with monitoring selection change events as well as keyboard events. There is no
implied association between keyboard events and selection change events - it is up to the
skin (or other listener) to create that association. So, I might say that, by definition,
you need to listen for both types of events in order to implement the logic you describe.

I don't think that hacking the listener list is a great approach, though. Seems like...well,
a hack.  :-)

On Jun 8, 2010, at 1:20 PM, Chris Bartlett wrote:

> I have a question about the preferred way to modify event related behaviour defined in
a component's skin.
> A simple example might be to modify the behaviour of a ListView responding to key presses.
> (To keep this example simple, I will assume that all list items are enabled.)
> If the first list item is selected (index 0) when the UP key is pressed, I want the selection
to jump to the last list item.
> Similarly, if the last list item is selected when the DOWN key is pressed the selection
should change to the first list item.
> org.apache.pivot.wtk.skin.terra.TerraListViewSkin handles UP & DOWN key press events
and is installed as the first ComponentKeyListener on the component.
> As I understand things, this listener code changes the selected list item before any
custom listeners are called.
> Custom listeners therefore do not know if the list item has just been changed from index
1 to index 0 (a press of the UP key handled by the default skin listener).
> This means that they do not know whether they need take further action in order to alter
the selection as described, or do nothing.
> I have previously accomplished similar things by 
> a) grabbing a reference to the relevant listener from the listener
> b) removing that listener from the listener list
> c) populating a custom 'prioritised' ComponentKeyListener with my own high priority listener
which functions as desired, as well as the original listener as a low priority
> (This calls the listeners in order of highest priority until one has consumed the event)
> d) adding the custom listener back into the listener list
> This results in my listener being called first, and only calls the default listener (from
the skin) if I haven't already handled the event.
> What is the preferred method of achieving this sort of thing with Pivot?
> Should I create a modified version of TerraListViewSkin which overrides the 'problem'
code and set this against the specific ListView?
> I can see this being likely if the custom listener could not do all it needed to using
publicly accessible API methods of the given component, and instead needed to directly interact
with any private instance data held by the skin.
> I imagine (or rather hope!) that the preferred method would not involve additional listeners
to track the selection states between keypresses.
> Regards,
> Chris

View raw message