Yes, this is OK. When the selection changes indirectly, we don't need to preview it.
On Sep 7, 2010, at 12:26 PM, Chris Bartlett wrote: > Agreed, the inconsistency between the selected tab button and selected tab > pane needs to be addressed. > > On the subject of TabPane selection changes, is it correct for the add & > remove methods of TabPane.TabSequence to change the selected index without > first running it by TabPaneSelectionListener#previewSelectedIndexChange()? > This seems to limit the utility of TabPaneSelectionListener, and is possibly > related to indirect selection changes ( > https://issues.apache.org/jira/browse/PIVOT-548) > > Chris > > On 7 September 2010 04:13, Greg Brown <[email protected]> wrote: > >> Forwarding to the dev list since this is a platform issue. >> >> Begin forwarded message: >> >>> From: Greg Brown <[email protected]> >>> Date: September 6, 2010 5:02:38 PM EDT >>> To: [email protected] >>> Subject: Re: TabPane selections >>> Reply-To: [email protected] >>> >>> Both DENY and DEFER are a form of veto. A "defer" vote means "I don't >> agree right now, but if you ask me again later, I will agree", whereas >> "deny" means "I don't agree now and I make no guarantee about what might >> vote might be later". So, it may be OK for TerraTabPaneSkin to behave this >> way in response to a "defer", but not a "deny". >>> >>> Maybe we need to reset the prior button group selection in >> selectedIndexChangeVetoed()? >>> >>> On Sep 6, 2010, at 4:08 PM, Chris Bartlett wrote: >>> >>>> How should a TabPane behave if it has a TabPaneSelectionListener which >> always returns Vote.DENY in the previewSelectedIndexChange() method? (A >> contrived example, but demonstrates the point) >>>> >>>> With TerraTabPaneSkin, if I select a tab by clicking the mouse on an >> enabled TabButton, the selection change is vetoed. >>>> However by this point, the 'target' TabButton has been selected and >> repainted and the TabPane's appearance is left in an inconsistent state. >>>> >>>> >>>> If TabPaneSelectionListener#previewSelectedIndexChange() provides the >> ability to veto, shouldn't it be tied in to the enabled state of the various >> tabs? >>>> That might open a can of worms though, as the votes returned by the >> various TabPaneSelectionListeners might change arbitrarily. >>>> >>>> Enabling & disabling tabs seem to provide similar functionality, with >> the exception of the TabPaneSelectionListener#selectedIndexChangeVetoed() >> method, which I suppose could be used to explain to the user why they are >> not able to select an enabled tab >>>> Enabling & disabling tabs has the advantage of updating the GUI to >> indicate the availability of the tabs for selection >>>> >>>> Regards, >>>> >>>> Chris >>> >> >>
