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] > <mailto:[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] > <mailto:[email protected]>> > Date: Thu, Oct 6, 2011 6:57 pm > Subject: Component#isEnabled does not affect appearance recursively > To: <[email protected] <mailto:[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? > >
