Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.29 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Thu, 1 Mar 2012 13:49:08 -0800
Subject: Re: s:Spacer (was Re: Missing Spark components)
Thread-Topic: s:Spacer (was Re: Missing Spark components)
Thread-Index: Acz38sX/p5FHcCaUTxytIc7zSUNjwwAAlsHV
Message-ID: <CB752ED4.3CFF7%aharui@adobe.com>
In-Reply-To: 
 <CACK5iZebo01oG0CeBrdE+RaHWYDdqvct7mqQCFJec4ebyDgBeA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 3/1/12 1:31 PM, "Om" <bigosmallm@gmail.com> wrote:

> On Thu, Mar 1, 2012 at 1:18 PM, Alex Harui <aharui@adobe.com> wrote:
>=20
>>=20
>>=20
>>=20
>> On 3/1/12 12:37 PM, "Om" <bigosmallm@gmail.com> wrote:
>>=20
>>> It might not be a very common use case, but it is a valid use case
>>> nevertheless.
>> I would prefer that we don't try to serve the uncommon use case.  Why ma=
ke
>> everyone pay for a full UIComponent just for space?  You are welcome to
>> create a sample "SpacerWithToolTip" component.
>>=20
>=20
> How about we create a s:SpacerLightWeight (switched order of words to hel=
p
> during autocomplete) that extends off of s:Rect.  And make s:Spacer work
> just like mx:Spacer.  This way we achieve both goals :-)
>=20
I don't fully agree.  I would guess the vast majority of folks don't need
tooltips on Spacer and will choose s:Spacer by default.  They should get a
default lightweight one and upgrade to a heavier one in the uncommon case.
Also, SpacerLightWeight doesn't tell you what it doesn't have, but
SpacerWithToolTip does.
>=20
>>=20
>>> mx:Spacer supports everything that UIComponent supports.
>> Shooting for 100% parity with MX is not a good idea, IMHO.
>>=20
>=20
> See, I have a problem with this.  Why would we not want to do that?  The
> ideal scenario is keep the interface same/similar but support everything.
> Internally, we can do things efficiently.
Well, it is probably too late.  Many APIs that do similar things have new
names and you probably don't want duplicate copies of APIs.  Secondly, not
everything in MX is worth keeping.  Like the fact that
verticalScrollPosition on mx:List is per-row not per-pixel.  That's probabl=
y
worth changing some code to get.

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui