pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gk_br...@verizon.net>
Subject Re: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance recursively
Date Tue, 11 Oct 2011 06:01:20 GMT
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