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 00:27:02 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message