Mailing-List: contact user-help@pivot.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@pivot.apache.org
Received-SPF: pass (athena.apache.org: domain of noelgrandin@gmail.com
 designates 74.125.82.182 as permitted sender)
Message-ID: <4E8EBFBF.3000607@gmail.com>
Date: Fri, 07 Oct 2011 11:00:47 +0200
From: Noel Grandin <noelgrandin@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: user@pivot.apache.org
CC: Bill van Melle <bill.van.melle@gmail.com>,
 Greg Brown <gk_brown@verizon.net>
Subject: Re: Component#isEnabled does not affect appearance recursively
References: <0LSO00J0HDS8NUZ4@vms173001.mailsrvcs.net>
 <CAAaiUA5Csdj-mR4HE0iYfv-a0TYF+Qv7w_OchCdNhzzfYBVrqg@mail.gmail.com>
In-Reply-To: 
 <CAAaiUA5Csdj-mR4HE0iYfv-a0TYF+Qv7w_OchCdNhzzfYBVrqg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090605050400030404070602"

This is a multi-part message in MIME format.
--------------090605050400030404070602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Yes, Swing does it this way.

It's tricky because sometimes you want setEnabled() to be recursive, and sometimes you don't.
For example, sometimes you want to disable tabbing, so you call TabbedPane#setEnabled(false), but you don't want the
children disabled.

Personally, I think we should add a utility method setEnabledRecursive(boolean) to the container classes.

-- Noel Grandin


Bill van Melle wrote:
> But I don't get why a component would ever want to paint itself to look like the user could interact with it if, in
> fact, they can't.  Wouldn't that be a violation of UI design principles?
>
> Are there other toolkits that do it the Pivot way?
>
>
> On Thu, Oct 6, 2011 at 8:02 PM, Greg Brown <gk_brown@verizon.net <mailto:gk_brown@verizon.net>> wrote:
>
>     This is actually by design. The skins could paint their state based on isBlocked(), but that didn't seem like the
>     right thing to do (at least, not all the time). But maybe it is something that could be configured by a style.
>
>
>     ----- Reply message -----
>     From: "Bill van Melle" <bill.van.melle@gmail.com <mailto:bill.van.melle@gmail.com>>
>     Date: Thu, Oct 6, 2011 6:57 pm
>     Subject: Component#isEnabled does not affect appearance recursively
>     To: <user@pivot.apache.org <mailto:user@pivot.apache.org>>
>
>     For a long time, I've been thinking that Pivot does a particularly poor job of making disabled controls visually
>     different, but I finally realized what's going on.
>     If you have a simple component with enabled=false, it is rendered in a visually distinct "grayed-out" way, like
>     other toolkits do.  However, if you have a container with  enabled=false, its children render normally.  If you
>     want a whole container to be disabled, and you want it to look like it's disabled, you have to disable the
>     children one by one (and keep track of which ones should remain disabled for when you want to re-enable the
>     container)!  That's not true in other toolkits I've used. Am I missing something?
>
>     I see there is a method Component#isBlocked, which provides the needed functionality, but it looks like it's only
>     being used by the event propagation code.  Seems to me there is a whole lot of paint code in the system for which
>     something.isEnabled() ought to be replaced by !something.isBlocked().  Yes?
>
>


--------------090605050400030404070602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Yes, Swing does it this way.<br>
    <br>
    It's tricky because sometimes you want setEnabled() to be recursive,
    and sometimes you don't.<br>
    For example, sometimes you want to disable tabbing, so you call
    TabbedPane#setEnabled(false), but you don't want the children
    disabled.<br>
    <br>
    Personally, I think we should add a utility method
    setEnabledRecursive(boolean) to the container classes.<br>
    <br>
    -- Noel Grandin<br>
    <br>
    <br>
    Bill van Melle wrote:
    <blockquote
cite="mid:CAAaiUA5Csdj-mR4HE0iYfv-a0TYF+Qv7w_OchCdNhzzfYBVrqg@mail.gmail.com"
      type="cite">
      <div>But I don't get why a component would ever want to paint
        itself to look like the user could interact with it if, in fact,
        they can't. &nbsp;Wouldn't that be a violation of UI design
        principles? </div>
      <div><br>
      </div>
      <div>Are there other toolkits that do it the Pivot way?<br>
      </div>
      <div><br>
      </div>
      <br>
      <div class="gmail_quote">On Thu, Oct 6, 2011 at 8:02 PM, Greg
        Brown <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:gk_brown@verizon.net">gk_brown@verizon.net</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">This is
          actually by design. The skins could paint their state based on
          isBlocked(), but that didn't seem like the right thing to do
          (at least, not all the time). But maybe it is something that
          could be configured by a style.<br>
          <br>
          <br>
          <div>----- Reply message -----<br>
            From: "Bill van Melle" &lt;<a moz-do-not-send="true"
              href="mailto:bill.van.melle@gmail.com" target="_blank">bill.van.melle@gmail.com</a>&gt;<br>
            Date: Thu, Oct 6, 2011 6:57 pm<br>
            Subject: Component#isEnabled does not affect appearance
            recursively<br>
            To: &lt;<a moz-do-not-send="true"
              href="mailto:user@pivot.apache.org" target="_blank">user@pivot.apache.org</a>&gt;<br>
            <br>
          </div>
          <div>For a long time, I've been thinking that Pivot does a
            particularly poor job of making disabled controls visually
            different, but I finally realized what's going on.</div>
          <div>If you have a simple component with enabled=false, it is
            rendered in a visually distinct "grayed-out" way, like other
            toolkits do. &nbsp;However, if you have a container with&nbsp;
            enabled=false, its children render normally.
            &nbsp;If you want a whole container to be disabled, and you want
            it to look like it's disabled, you have to disable the
            children one by one (and keep track of which ones should
            remain disabled for when you want to re-enable the
            container)! &nbsp;That's not true in other toolkits I've used. Am
            I missing something?</div>
          <div><br>
          </div>
          <div>I see there is a method Component#isBlocked, which
            provides the needed functionality, but it looks like it's
            only being used by the event propagation code. &nbsp;Seems to me
            there is a whole lot of paint code in the system for which
            something.isEnabled() ought to be replaced by
            !something.isBlocked(). &nbsp;Yes?</div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------090605050400030404070602--