Components, Containers and disabling

[Noel Grandin <no...@gmail.com>]

Hi

I note that some widget classes (e.g. Slider, Calendar) extend Container.

Do we perhaps need a split between the concept of CompositeComponent and
LayoutContainer, since a CompositeComponent is only really allowed to be
manipulated by it's Skin,
whereas a LayoutContainer may have child components add/removed by anyone.

Which leads to another interesting discussion - is it possible to
recursively disable/enable a hierarchy of components, and how to do this
safely and easily.
This is tricky to implement externally to a hierarchy because the
hierarchy may contain user-defined widgets that don't like having their
child components enabled/disabled.

Regards, Noel Grandin

Re: Components, Containers and disabling

[Greg Brown <gk...@mac.com>]

>Which is why I'd like to see a setEnabledRecursive() method at Component
>level, so that sub-classes could override it and DTRT.

Sure. But it's not the *component* that defines the "right thing", it's the application. The right behavior for one app is not necessarily the same as another.

>But there are always other hacks available, like using a transparent
>pane to temporarily block a group of components.

You can do this in Pivot, but it's not necessary since disabling a container automatically blocks access to all of its children (IIRC, this is different than Swing, which does not have this capability). You can also attach a decorator (such as a ShadeDecorator or BlurDecorator) to indicate that your container is disabled.

G

Re: Components, Containers and disabling

[Noel Grandin <no...@gmail.com>]

Greg Brown wrote:
> I think it's probably tricky to implement in any framework because it requires too many assumptions about what the "correct" behavior is. For example, when you re-enable an ancestor, do you recursively re-enable all child components? What about child components that were previously disabled? For this reason, we decided to leave the implementation of this type of functionality to the application developer.
>
>   
Which is why I'd like to see a setEnabledRecursive() method at Component
level, so that sub-classes could override it and DTRT.

But there are always other hacks available, like using a transparent
pane to temporarily block a group of components.

Regards, Noel Grandin.

Re: Components, Containers and disabling

[Greg Brown <gk...@mac.com>]

>But that's the point - how do I make an entire hierarchy of components
>show that they are disabled.

The skins would need to be aware of the "blocked" state, and all ancestor skins would need to ensure that they repaint when their enabled states change.

>It's quite a common requirement, and it's fairly tricky to implement
>well in Swing because some of the composite components don't like me
>calling setEnabled() on their children, so doing a straightforward
>traversal of the tree is problematic.

I think it's probably tricky to implement in any framework because it requires too many assumptions about what the "correct" behavior is. For example, when you re-enable an ancestor, do you recursively re-enable all child components? What about child components that were previously disabled? For this reason, we decided to leave the implementation of this type of functionality to the application developer.

Re: Components, Containers and disabling

[Noel Grandin <no...@gmail.com>]

Greg Brown wrote:
>> Which leads to another interesting discussion - is it possible to
>> recursively disable/enable a hierarchy of components, and how to do this
>> safely and easily.
>>     
>
> Disabling an ancestor implicitly disables the descendants - they won't show their "disabled" states, but you won't be able to interact with them. You may find the isBlocked() method useful - isEnabled() returns true if a component is itself disabled, and isBlocked() returns true if the component or any of its descedants are disabled.
>   
But that's the point - how do I make an entire hierarchy of components
show that they are disabled.
It's quite a common requirement, and it's fairly tricky to implement
well in Swing because some of the composite components don't like me
calling setEnabled() on their children, so doing a straightforward
traversal of the tree is problematic.
I have solved it in the general case using various hacks (including
reflection) but it's not pretty.

Regards, Noel Grandin

Re: Components, Containers and disabling

[Greg Brown <gk...@mac.com>]

>Do we perhaps need a split between the concept of CompositeComponent and
>LayoutContainer, since a CompositeComponent is only really allowed to be
>manipulated by it's Skin,
>whereas a LayoutContainer may have child components add/removed by anyone.

Pivot does make a conceptual distinction between containers that are used for navigation, for layout, and as composites, but we don't impose any API restrictions - and I'm not sure we can. The skin is simply just another public caller - there's no way to say "it's OK for the skin to add components, but not anyone else". So I think this is probably just a documentation issue.

>Which leads to another interesting discussion - is it possible to
>recursively disable/enable a hierarchy of components, and how to do this
>safely and easily.

Disabling an ancestor implicitly disables the descendants - they won't show their "disabled" states, but you won't be able to interact with them. You may find the isBlocked() method useful - isEnabled() returns true if a component is itself disabled, and isBlocked() returns true if the component or any of its descedants are disabled.