pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance recursively
Date Tue, 11 Oct 2011 07:39:51 GMT
Hi all,

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

>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.
Are we sure this is the right way to do this ?
Greg what do you think ?

If it is, we can do it in 2.1, and add this as a comment, to have more
info in the issue.

Sandro


2011/10/11 Greg Brown <gk_brown@verizon.net>:
> 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 <gk_brown@verizon.net> 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)
>>>> <jira@apache.org> 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
>>>
>>>
>
>

Mime
View raw message