pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger L. Whitcomb" <Roger.Whitc...@actian.com>
Subject RE: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance recursively
Date Tue, 11 Oct 2011 15:56:29 GMT
I could try prototyping this.  I have several panels where I set the container disabled, so
I could test fairly easily.

Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@actian.com| Actian Corp. | 500
Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  | +1 650-587-5596 | fax:
+1 650-587-5550


-----Original Message-----
From: Greg Brown [mailto:gk_brown@verizon.net] 
Sent: Tuesday, October 11, 2011 7:35 AM
To: dev@pivot.apache.org
Subject: Re: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance
recursively

As I mentioned, I think that using isBlocked() to paint a disabled state would be preferable
to recursively calling setEnabled(), since it would preserve the enabled state of the subcomponents.
The only downside is that we'd now need to walk up the hierarchy for each component to determine
if it is blocked. That makes painting a bit heavier.

On Oct 11, 2011, at 12:39 AM, Sandro Martini wrote:

> 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