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 >
