Hi all, > Personally, I think we should add a utility method > setEnabledRecursive(boolean) to the container classes. I think this could be a good idea, and keep the current behavior as default.
Bill, can you file a Ticket for 2.1 ? Bye 2011/10/7 Noel Grandin <[email protected]>: > > Yes, Swing does it this way. > > It's tricky because sometimes you want setEnabled() to be recursive, and > sometimes you don't. > For example, sometimes you want to disable tabbing, so you call > TabbedPane#setEnabled(false), but you don't want the children disabled. > > Personally, I think we should add a utility method > setEnabledRecursive(boolean) to the container classes. > > -- Noel Grandin > > > Bill van Melle wrote: > > But I don't get why a component would ever want to paint itself to look like > the user could interact with it if, in fact, they can't. Wouldn't that be a > violation of UI design principles? > Are there other toolkits that do it the Pivot way? > > > On Thu, Oct 6, 2011 at 8:02 PM, Greg Brown <[email protected]> wrote: >> >> This is actually by design. The skins could paint their state based on >> isBlocked(), but that didn't seem like the right thing to do (at least, not >> all the time). But maybe it is something that could be configured by a >> style. >> >> >> ----- Reply message ----- >> From: "Bill van Melle" <[email protected]> >> Date: Thu, Oct 6, 2011 6:57 pm >> Subject: Component#isEnabled does not affect appearance recursively >> To: <[email protected]> >> >> For a long time, I've been thinking that Pivot does a particularly poor >> job of making disabled controls visually different, but I finally realized >> what's going on. >> If you have a simple component with enabled=false, it is rendered in a >> visually distinct "grayed-out" way, like other toolkits do. However, if you >> have a container with enabled=false, its children render normally. If you >> want a whole container to be disabled, and you want it to look like it's >> disabled, you have to disable the children one by one (and keep track of >> which ones should remain disabled for when you want to re-enable the >> container)! That's not true in other toolkits I've used. Am I missing >> something? >> I see there is a method Component#isBlocked, which provides the needed >> functionality, but it looks like it's only being used by the event >> propagation code. Seems to me there is a whole lot of paint code in the >> system for which something.isEnabled() ought to be replaced by >> !something.isBlocked(). Yes? > >
