I think we need to sometimes let it go and just make changes to our
original code. In our Jewel application we are preserving around 30% of
code of ported Flex app, by our choice. The rest is just rewritten. Even in
that rewritten code when I'm seeing some UI, layout issue - I don't waste
huge amount of time if I can simply make it work by one line of CSS.
It just allows you to move forward. I know it is hard sometimes convince
the client to make the changes, but our job as a power users of this
framework is educate also that Royale won't provide 100% conversion.
Changes in the old code is in many cases inevitable.
Thanks,
Piotr
pt., 5 cze 2020 o 11:36 Greg Dove <greg.d...@gmail.com> napisał(a):
>
> thanks Serkan - you are right - I did not see that explanation earlier
> (just the screencaptures) which is why I asked my extra question.
>
> It sounds like it could be similar to what I was addressing, but I don't
> have a 'universal' solution (and possibly not even a 'good' selective
> solution, which is why I am keen for extra eyes on it), but it might be
> useful as-is, or possibly give Alex, you or anyone else some other
> approaches to consider. I am happy to collaborate on an approach once we
> settle on one that makes sense for all of us.
>
>
> On Fri, Jun 5, 2020 at 2:29 PM serkan <ser...@likyateknoloji.com> wrote:
>
>>
>> I am not sure but I guess mail not sent to the list Greg :)
>>
>> My application heavily use states to manage visual layout Greg. Alex is
>> working on the issues one by one as open an issue.
>>
>> They are mostly with percentage based.
>>
>> e.g.
>>
>> <jobdetail:JobAllDetailPanel includeIn="jobDetailState" id="allJobDetail"
>> height="100%"/>
>>
>> This component is the one et the center with name "İş Tüm Detay Formu"
>> which is very ugly displayed in Royale.
>>
>> Some fix works at first like menu bar but as you can see when resize, it
>> is broken again :)
>>
>> Thank
>> Serkan
>>
>> 4.06.2020 13:08 tarihinde Greg Dove yazdı:
>>
>>
>> Thanks Serkan,
>>
>> Do you think you are seeing the same type of issue I described? Are any
>> of those controls being added either via states or via code at runtime into
>> containers that have percentage based dimensions?
>>
>> I think that the changes I have won't break anyone's existing layouts,
>> but I am not sure yet if I should push them as is to develop or not,
>> because this is the first time I looked at emulation layout stuff.
>> I do see improvements for the issues I have been facing, but there still
>> might be more things that need attention, or I may not be addressing things
>> in the right way.
>>
>> @aharui : when you get to see this, what do you think? Would you have
>> time to take a look at this? And do you think I can push what I have to
>> develop or should it go in a branch?
>> (I can monkey patch my client project so we can use these 'fixes' for
>> local progress in the interim if I need to).
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 4, 2020 at 8:52 PM serkan <ser...@likyateknoloji.com> wrote:
>>
>>> Hi Greg,
>>>
>>> Yes I am.
>>>
>>> Here is my case :
>>> Flex:
>>>
>>>
>>>
>>> Emulation :
>>>
>>>
>>>
>>> Thanks,
>>> Serkan
>>>
>>> 4.06.2020 11:12 tarihinde Greg Dove yazdı:
>>>
>>> Hi,
>>>
>>> Just wondered if anyone else is dealing with layout issues in Flex
>>> emulation. I have some layout issues that are slowing my progress on a
>>> project, and I'd like to resolve them as quickly as I can.
>>>
>>> In particular, I see issues with BoxLayout-based containers which have
>>> percentWidth or percentHeight set. These don't get determined as having
>>> width or height 'SizedToContent' when performing layout, but in many
>>> situations they behave in a similar way (they can change their size based
>>> on their content in terms of layout rules applied by the parent container).
>>> This is because in Flex, percentages are not simply a percentage of their
>>> parent, but they follow something perhaps a little closer to flexbox layout
>>> rules for all the percentWidth or percentHeight siblings (managed by their
>>> parent's layout). In other words, they are also related to the measured
>>> size of their content if the parent needs to manage them (I'm not sure how
>>> best to describe this, but I think that sort of captures it). They can
>>> expand beyond their percent allocation or contract below it depending on
>>> their measured sizes.
>>> I think the layouts work downward for this, but changes in the children
>>> don't seem to trigger the parent layout.
>>>
>>> An example might be
>>> <mx:HBox id='addThingsToMe' width='50%' />
>>>
>>> If you have the above at the application level (where the application has
>>> vertical layout) and keep adding buttons (for example) to the HBox via a UI
>>> test button that adds a new Button to that on each click, then it should
>>> expand horizontally greater than 50% width when the volume of buttons
>>> exceeds its nominal 50% width. It is definitely easier to see this if you
>>> add a border to the container.
>>>
>>> I have been working on this, and made progress, but the approach I am using
>>> feels a bit patchwork, and just wondered whether others are seeing anything
>>> like this, and/or how it has been addressed elsewhere....
>>>
>>> Here's a summary of some of the things I have been trying, which do yield
>>> improvements, but don't really solve the problem completely:
>>>
>>> 1. added extra listener for 'childrenRemoved' in BoxLayout strand setter.
>>>
>>> 2. Created a new mx 'ContainerView' class
>>> (mx.containers.beads.ContainerView extends
>>> org.apache.royale.html.beads.ContainerView)
>>> This has the following in it:
>>>
>>> private var widthBefore:Number = -1
>>> private var heightBefore:Number = -1;
>>> private var sizeChangedBeforeLayout:Boolean;
>>>
>>> COMPILE::JS
>>> override public function beforeLayout():Boolean
>>> {
>>> var container:Container = host as Container;
>>>
>>> sizeChangedBeforeLayout = (widthBefore != container.width || heightBefore
>>> != container.height);
>>> widthBefore = container.width;
>>> heightBefore = container.height;
>>> return super.beforeLayout();
>>> }
>>>
>>> COMPILE::JS
>>> override public function afterLayout():void
>>> {
>>> var container:Container = host as Container;
>>> //size might change during layout
>>> var sizeChangedDuringLayout:Boolean = !sizeChangedBeforeLayout &&
>>> (widthBefore != container.width || heightBefore != container.height);
>>> if (sizeChangedDuringLayout) {
>>> //prepare for next time
>>> widthBefore = container.width;
>>> heightBefore = container.height;
>>> }
>>> var requestParentLayout:Boolean = sizeChangedBeforeLayout
>>> || sizeChangedDuringLayout
>>> || (!isNaN(container.percentWidth) && container.width <
>>> container.measuredWidth) || (!isNaN(container.percentHeight) &&
>>> container.height < container.measuredHeight);
>>> if (requestParentLayout && container.parent is Container) {
>>> trace('requesting parent layout of ',(container as
>>> Object).ROYALE_CLASS_INFO.names[0].qName );
>>> (container.parent as Container).layoutNeeded();
>>> }
>>> }
>>>
>>> That is pretty much it, and it is being used as a replacement in my local
>>> MXRoyale css for Container:
>>>
>>> /*IBeadView:
>>> ClassReference("org.apache.royale.html.beads.ContainerView");*/
>>> IBeadView: ClassReference("mx.containers.beads.ContainerView");
>>>
>>> I'm not saying this is right, but it does help quite a bit with what I am
>>> facing.
>>>
>>> In addition to BoxLayout in general, I have been working on the
>>> Grid/GridRow/GridItem layouts which are more specific in terms of layout
>>> changes needed, but also can have similar problems.
>>>
>>>
>>> Although I am seeing improvements with what I have done so far, I'm not
>>> really satisfied with it, and I am keen for input/discussion (or
>>> collaboration). I have been pursuing what I would mostly describe as a
>>> 'workaround' approach, so would welcome any thoughts on how best to tackle
>>> this.
>>> I think there is something missing because of the way Flex does layouts vs.
>>> the way Royale does it, but I can't describe it fully yet. Perhaps things
>>> are only currently envisaged to work with mxml declarative content onto
>>> display and not so much with dynamic updates. But I think state-based
>>> changes could have similar effects for some of these things if they happen
>>> inside containers that have their own percent dimensions.
>>>
>>>
>>> Thanks,
>>> Greg
>>>
>>>
>>>
>>>
>>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
