On Fri, Oct 7, 2011 at 2:00 AM, Noel Grandin <[email protected]> wrote:
> > Yes, Swing does it this way. > Wow, I'm really surprised. I see there are Swing users who have my question, too (e.g., http://stackoverflow.com/questions/2713425/java-swing-how-to-disable-a-jpanelor http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4177727). The bug submitter in the latter asserts that AWT does it the "expected" way of disabling the entire container, th Windows Forms and WPF do the "right" thing when disabling a container, which probably shows you my experiential bias. 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. > I assume you mean TabPane. Could you explain the use case? Disabling a TabPane certainly prevents the user from changing tabs, but it also prevents interaction with the current tab. Why would you want to leave it looking like the user could interact with it? > 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? >> > > >
