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 <[email protected]>: > 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 >>> >>> > >
