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 <gk_brown@verizon.net> 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" <bill.van.melle@gmail.com>
Date: Thu, Oct 6, 2011 6:57 pm
Subject: Component#isEnabled does not affect appearance recursively
To: <user@pivot.apache.org>

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?