Did you try applying a decorator to your container? For example, ShadeDecorator
might work.
On Oct 10, 2011, at 5:27 PM, Bill van Melle wrote:
> Exactly. I think Noel is being distracted by the proposal for a
> setEnabledRecursive(boolean) in the original ticket. I wish we could change
> that, because it's not at all what I would have written had Sandro not
> beaten me to submitting the request.
>
> As for workarounds, earlier in this thread you said,
>
> Alternatively, a UI designer may want to paint a semi-transparent overlay
>> over a container to show that it is disabled, rather than having each
>> subcontrol paint its own disabled state."
>
>
> and I said I considered doing that myself as a workaround. Well, now I've
> tried to do so, and I can't see how to in a non-painful way. I started
> naively defining a new skin for TablePane (the container I'd most want this
> behavior from):
>
> public class TablePaneSkinWithDisableAwareness extends TerraTablePaneSkin {
> @Override
> public void paint(Graphics2D graphics) {
> super.paint(graphics);
> if (getComponent().isBlocked()) {
> graphics.setPaint(new Color(100, 100, 100, 127));
> graphics.fillRect(0, 0, getWidth(), getHeight());
> }
> }
> }
>
> but all this does is dim the background (and I don't especially want that
> anyway) -- the children are painted *after* the skin gets its shot. So it
> seems like the only way I could make it work is to extend TablePane,
> override *its* paint to do something after its children get painted, and
> then change every TablePane in my program to use the new class. Ugh. Am I
> missing something?
>
> So at this point it would be much easier for me to do a global replace of
> xxx.isEnabled() with !xxx.isBlocked() in the skin sources, but I really
> would rather not be in the business of maintaining forked Pivot libraries.
>
>
> On Sat, Oct 8, 2011 at 4:28 PM, Greg Brown <[email protected]> wrote:
>
>> But again, the problem with recursively setting the enabled flag is that
>> you blow away any existing state. That's why I think simply painting the
>> disabled state when isBlocked() is true would be preferable.
>>
>> On Oct 8, 2011, at 1:10 AM, Noel Grandin wrote:
>>
>>> On Sat, Oct 8, 2011 at 01:49, Bill van Melle (Commented) (JIRA)
>>> <[email protected]> wrote:
>>>> In particular, it is important that setting enabled to true for the
>> container not suddenly enable children that had been disabled before the
>> container was >disabled.
>>>>
>>>
>>> This is what makes any solution extremely hard. What happens if I do
>> this:
>>> container.setEnabled(false);
>>> child1.setEnabled(false);
>>> container.setEnabled(true);
>>>
>>> What is the right set of children to re-enable?
>>> There is no right answer.
>>>
>>> I do not believe that we can build behaviour that will satisfy all
>> use-cases.
>>> The best we can do is to provide some tools to make it easier to
>>> achieve various ends.
>>>
>>> To that end, my proposed solution is:
>>> (1) setEnabled(boolean) does what it does now
>>> (2) setEnabledRecursive(boolean) is defined at the Container level,
>>> walks all the way down it's tree, affecting every element.
>>>
>>> If you want behaviour different from this, you will have to override
>>> setEnabled() and setEnabledRecursive() and implement your own logic.
>>>
>>> Anything else is simply not going to satisfy all users. I know - I've
>>> had this discussion before on the SwingX mailing list.
>>>
>>> -- Noel Grandin
>>
>>
