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? >
