You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Héctor A <ne...@gmail.com> on 2015/05/07 11:01:59 UTC
Layout problem
A designer has sent me the following layout of a mobile view:
<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark" title="nuevaPortada"
tabBarVisible="false">
<s:Image id="cabecera" source="@Embed('../img/home_cabecera.jpg')"
scaleX="0.5" scaleY="0.5" smooth="true" horizontalCenter="0" />
<s:VGroup gap="0" width="100%" top="180">
<s:HGroup gap="0" width="100%">
<s:Image source="@Embed('../img/home_btn_imagen.jpg')"
scaleX="0.5" scaleY="0.5" smooth="true" width="50%" />
<s:Image source="@Embed('../img/home_btn_producto.jpg')"
scaleX="0.5" scaleY="0.5" smooth="true" width="50%" />
</s:HGroup>
<s:HGroup gap="0" width="100%">
<s:Image source="@Embed('../img/home_btn_categoria.jpg')"
scaleX="0.5" scaleY="0.5" smooth="true" width="50%" />
<s:Image source="@Embed('../img/home_btn_micuenta.jpg')"
scaleX="0.5" scaleY="0.5" smooth="true" width="50%" />
</s:HGroup>
</s:VGroup>
</s:View>
However that view is not working as expected. The problem is those images
width=”50%” are working as expected, but original height is kept, causing
an unwanted border between both HGroups. I know this can be solved through
code, but the designer is expecting this problem to be solvable by only
MXML, is there any attribute that can set the expected behavior? We don’t
want designers to think that passing layouts to Flex is a sh*t ;P, as this
would work as expected in HTML.
Best regards,
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
Using the MXML in the original mail:
http://imgbox.com/5JcXcQju
However for some reason, after the width exceeds some value, width=50%
seems to stop working, or maybe some maxHeight is reached? and I get this:
http://imgbox.com/Sb6fkDW4
Using a BitmapImage the result is the desired (also, note, that in this
case scaleX and scaleY doesn't make any difference, as width is constrained
by the 50%, and the height seems to be dependent of the height).
http://imgbox.com/TsfJgT57
http://imgbox.com/mobddmWR
On Thu, May 7, 2015 at 5:09 PM, Alex Harui <ah...@adobe.com> wrote:
> Can you post a link to a screenshot of what you are seeing?
>
> -Alex
>
> On 5/7/15, 7:21 AM, "Héctor A" <ne...@gmail.com> wrote:
>
> >I've been making some tests on my own. On some of them the number of
> >Images
> >inside each HGroup seemed to affect how the layout was performed, strange.
> >Anyway, I've seen that using BitmapImage instead of Image (with
> >scaleMode="letterbox", of course) gave the desired result, and since this
> >case doesn't require any special loading control nor skin the designer can
> >follow this route, and since BitmapImage performs better, +1 to it, but it
> >would be nice to see this behaviour in an Image control.
> >
> >On Thu, May 7, 2015 at 12:35 PM, Héctor A <ne...@gmail.com> wrote:
> >
> >> Maybe a -1 could be passed to height or width to simulate "auto".
> >>
> >> On Thu, May 7, 2015 at 12:32 PM, Héctor A <ne...@gmail.com> wrote:
> >>
> >>> I guess it's this same issue:
> >>>
> >>>
> >>>
> >>>
> http://stackoverflow.com/questions/21132203/flash-spark-image-width-100-
> >>>height-auto
> >>>
> >>> So still no workaround in pure MXML? Seems a bit of a letdown, would be
> >>> nice to have and may even be common sense. I'd say we all needed it at
> >>> least once, but I've always resorted to use code.
> >>>
> >>> On Thu, May 7, 2015 at 11:25 AM, Héctor A <ne...@gmail.com>
> wrote:
> >>>
> >>>> Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly
> >>>> working as expected.
> >>>>
> >>>> On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com>
> >>>>wrote:
> >>>>
> >>>>> It also seemed strange to me. It's because of DPIs, the images were
> >>>>> done for 360DPI, targetting 180DPI.
> >>>>>
> >>>>> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On 07/05/15 10:01, Héctor A wrote:
> >>>>>>
> >>>>>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
> >>>>>>>
> >>>>>>
> >>>>>> What's the reasoning behind giving a scale factor for both axis as
> >>>>>> well as a width and expecting the height to adjust ?
> >>>>>>
> >>>>>> Tom
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Layout problem
Posted by Alex Harui <ah...@adobe.com>.
Can you post a link to a screenshot of what you are seeing?
-Alex
On 5/7/15, 7:21 AM, "Héctor A" <ne...@gmail.com> wrote:
>I've been making some tests on my own. On some of them the number of
>Images
>inside each HGroup seemed to affect how the layout was performed, strange.
>Anyway, I've seen that using BitmapImage instead of Image (with
>scaleMode="letterbox", of course) gave the desired result, and since this
>case doesn't require any special loading control nor skin the designer can
>follow this route, and since BitmapImage performs better, +1 to it, but it
>would be nice to see this behaviour in an Image control.
>
>On Thu, May 7, 2015 at 12:35 PM, Héctor A <ne...@gmail.com> wrote:
>
>> Maybe a -1 could be passed to height or width to simulate "auto".
>>
>> On Thu, May 7, 2015 at 12:32 PM, Héctor A <ne...@gmail.com> wrote:
>>
>>> I guess it's this same issue:
>>>
>>>
>>>
>>>http://stackoverflow.com/questions/21132203/flash-spark-image-width-100-
>>>height-auto
>>>
>>> So still no workaround in pure MXML? Seems a bit of a letdown, would be
>>> nice to have and may even be common sense. I'd say we all needed it at
>>> least once, but I've always resorted to use code.
>>>
>>> On Thu, May 7, 2015 at 11:25 AM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly
>>>> working as expected.
>>>>
>>>> On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com>
>>>>wrote:
>>>>
>>>>> It also seemed strange to me. It's because of DPIs, the images were
>>>>> done for 360DPI, targetting 180DPI.
>>>>>
>>>>> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On 07/05/15 10:01, Héctor A wrote:
>>>>>>
>>>>>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>>>>>>
>>>>>>
>>>>>> What's the reasoning behind giving a scale factor for both axis as
>>>>>> well as a width and expecting the height to adjust ?
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
I've been making some tests on my own. On some of them the number of Images
inside each HGroup seemed to affect how the layout was performed, strange.
Anyway, I've seen that using BitmapImage instead of Image (with
scaleMode="letterbox", of course) gave the desired result, and since this
case doesn't require any special loading control nor skin the designer can
follow this route, and since BitmapImage performs better, +1 to it, but it
would be nice to see this behaviour in an Image control.
On Thu, May 7, 2015 at 12:35 PM, Héctor A <ne...@gmail.com> wrote:
> Maybe a -1 could be passed to height or width to simulate "auto".
>
> On Thu, May 7, 2015 at 12:32 PM, Héctor A <ne...@gmail.com> wrote:
>
>> I guess it's this same issue:
>>
>>
>> http://stackoverflow.com/questions/21132203/flash-spark-image-width-100-height-auto
>>
>> So still no workaround in pure MXML? Seems a bit of a letdown, would be
>> nice to have and may even be common sense. I'd say we all needed it at
>> least once, but I've always resorted to use code.
>>
>> On Thu, May 7, 2015 at 11:25 AM, Héctor A <ne...@gmail.com> wrote:
>>
>>> Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly
>>> working as expected.
>>>
>>> On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> It also seemed strange to me. It's because of DPIs, the images were
>>>> done for 360DPI, targetting 180DPI.
>>>>
>>>> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 07/05/15 10:01, Héctor A wrote:
>>>>>
>>>>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>>>>>
>>>>>
>>>>> What's the reasoning behind giving a scale factor for both axis as
>>>>> well as a width and expecting the height to adjust ?
>>>>>
>>>>> Tom
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
Maybe a -1 could be passed to height or width to simulate "auto".
On Thu, May 7, 2015 at 12:32 PM, Héctor A <ne...@gmail.com> wrote:
> I guess it's this same issue:
>
>
> http://stackoverflow.com/questions/21132203/flash-spark-image-width-100-height-auto
>
> So still no workaround in pure MXML? Seems a bit of a letdown, would be
> nice to have and may even be common sense. I'd say we all needed it at
> least once, but I've always resorted to use code.
>
> On Thu, May 7, 2015 at 11:25 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly
>> working as expected.
>>
>> On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com> wrote:
>>
>>> It also seemed strange to me. It's because of DPIs, the images were done
>>> for 360DPI, targetting 180DPI.
>>>
>>> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com>
>>> wrote:
>>>
>>>>
>>>> On 07/05/15 10:01, Héctor A wrote:
>>>>
>>>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>>>>
>>>>
>>>> What's the reasoning behind giving a scale factor for both axis as well
>>>> as a width and expecting the height to adjust ?
>>>>
>>>> Tom
>>>>
>>>
>>>
>>
>
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
I guess it's this same issue:
http://stackoverflow.com/questions/21132203/flash-spark-image-width-100-height-auto
So still no workaround in pure MXML? Seems a bit of a letdown, would be
nice to have and may even be common sense. I'd say we all needed it at
least once, but I've always resorted to use code.
On Thu, May 7, 2015 at 11:25 AM, Héctor A <ne...@gmail.com> wrote:
> Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly
> working as expected.
>
> On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com> wrote:
>
>> It also seemed strange to me. It's because of DPIs, the images were done
>> for 360DPI, targetting 180DPI.
>>
>> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com>
>> wrote:
>>
>>>
>>> On 07/05/15 10:01, Héctor A wrote:
>>>
>>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>>>
>>>
>>> What's the reasoning behind giving a scale factor for both axis as well
>>> as a width and expecting the height to adjust ?
>>>
>>> Tom
>>>
>>
>>
>
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
Sorry, 320/160DPI. Anyway, that's not the issue, and it's seemingly working
as expected.
On Thu, May 7, 2015 at 11:18 AM, Héctor A <ne...@gmail.com> wrote:
> It also seemed strange to me. It's because of DPIs, the images were done
> for 360DPI, targetting 180DPI.
>
> On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com> wrote:
>
>>
>> On 07/05/15 10:01, Héctor A wrote:
>>
>>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>>
>>
>> What's the reasoning behind giving a scale factor for both axis as well
>> as a width and expecting the height to adjust ?
>>
>> Tom
>>
>
>
Re: Layout problem
Posted by Héctor A <ne...@gmail.com>.
It also seemed strange to me. It's because of DPIs, the images were done
for 360DPI, targetting 180DPI.
On Thu, May 7, 2015 at 11:06 AM, Tom Chiverton <tc...@extravision.com> wrote:
>
> On 07/05/15 10:01, Héctor A wrote:
>
>> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
>>
>
> What's the reasoning behind giving a scale factor for both axis as well as
> a width and expecting the height to adjust ?
>
> Tom
>
Re: Layout problem
Posted by Tom Chiverton <tc...@extravision.com>.
On 07/05/15 10:01, Héctor A wrote:
> scaleX="0.5" scaleY="0.5" smooth="true" width="50%"
What's the reasoning behind giving a scale factor for both axis as well
as a width and expecting the height to adjust ?
Tom