pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill van Melle <bill.van.me...@gmail.com>
Subject Re: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance recursively
Date Tue, 11 Oct 2011 23:08:50 GMT
On Tue, Oct 11, 2011 at 12:39 AM, Sandro Martini <sandro.martini@gmail.com>
wrote:

> Bill, if you have a better description for PIVOT-798, tell me (or
>
change directly, if you have enough right in jira).
>

No, I don't have that much power.  I would have said something like
"Components should paint using their "disabled" style if they or any
ancestor is disabled."  More direct would be "Component should use
isBlocked() instead of isEnabled() in deciding whether to paint in their
normal or disabled style", but maybe a description that leaves the
implementation details open is preferable.

On Tue, Oct 11, 2011 at 7:34 AM, Greg Brown <gk_brown@verizon.net> wrote:

> As I mentioned, I think that using isBlocked() to paint a disabled state
> would be preferable to recursively calling setEnabled(), since it would
> preserve the enabled state of the subcomponents. The only downside is that
> we'd now need to walk up the hierarchy for each component to determine if it
> is blocked. That makes painting a bit heavier.


Right, isBlocked() is more expensive than isEnabled().  I suppose you could
pay the cost at setEnabled time instead by giving every component a field
"ancestorIsDisabled", and have setEnabled overridden on Container to
recursively set or clear that new field as appropriate.     But I'm not sure
the added complexity would be worth the slight performance gain.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message