pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noel Grandin <noelgran...@gmail.com>
Subject Re: Component#isEnabled does not affect appearance recursively
Date Fri, 07 Oct 2011 09:00:47 GMT

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

-- 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 <gk_brown@verizon.net <mailto:gk_brown@verizon.net>>
>     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 <mailto: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 <mailto: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?

View raw message