Re: MXRoyale layout issues - questions/discussion
I hope to have time tomorrow. Looking quickly at the things you've tried to fix the problem, it occurs to me that the piece that is probably missing in MXRoyale is the propagation of something like invalidateSize() instead of just "layoutNeeded". My thinking is that in the general case the child can't really know that because something about the child changed that the parent needs to run a new layout and especially the parent of that parent. So some new plumbing may be needed where, when a component changes in a way that its measured or explicit size had changed (as opposed to the size change from the parent laying out the child), that some sort of layoutMightBeNeeded is sent to the parent which then uses its measurement code and explicit sizes to determine whether its size has changed and propagates a layoutMightBeNeeded to its parent. But if it decides its size has not changed, it would then run layout which should start the parents laying out children. We'll see if the test case points in that direction. HTH, -Alex On 6/5/20, 3:05 AM, "Greg Dove" wrote: Hi Alex, thanks for the detailed explanation and offer to take a look, for now some quick replies inline please add questions in the github issue if you want more details about anything I did so far. thanks Greg On Fri, Jun 5, 2020 at 6:50 PM Alex Harui wrote: > Greg, > > I think this thread got forked somehow. If you have a simple test case I > can try to look at it this weekend. > > Thanks. I added issue #849 [1] which should give you something to look at. I suggest you open the Flex build in a browser and then compare things to it in Royale. There are 2 royale builds as well with the same code in the other 2 zips. One without the modifications to MXRoyale and one with. The 'one with' zip also has the modified MXRoyale files, so you should be able to drop them in and overwrite in your local MXRoyale and build to test/review/change what I did. I'm the first to admit that I do think it doesn't feel right. But so far at least it does make a bunch of code work in one app with a lot of deeply nested layouts that was not working before. It certainly does not make everything work. But it helps quite a bit. Certainly appreciate any review/consideration. I am really keen to collaborate on a solution that makes sense for most here. I don't doubt that the changes you propose work for you, but they make me > nervous although I'm not the best at reading code and understanding what it > does. Here's a brain dump on layout in case it helps. > > So far they work better 'for me' I agree. But I think you probably know me enough by now to know that if I am confident that I have a contribution that is objectively good (passes unit tests compared with swf is my normal benchmark) then I will add it. Part of the reason I started this discussion is because I feel a bit the same way here. I am still learning this stuff and figuring things out, so I am not pushing it because I don't want to inflict anything that is not an objective improvement on others. In terms of describing it, the main thing I think, is that the view checks when layout happens if there was a size change since last time layout ran, or if there was a change in size during the current run. Then there is some somewhat awkward checking to see if the parent might be interested in this because there is some 'sizedToContent' aspect to it (which includes a percentage variation on that check). If we think it is relevant, then request the parent to layout. Is this likely to do it sometimes when it is not needed, I suspect so. But so far it has not caused any problems in the codebase I am working with. I'm also working on the Grid related stuff, but you could probably just ignore that for now and focus only on the BoxLayout stuff. In Flex, parents always size their children. The children probably > shouldn't override that size or if they do they have to be careful that it > doesn't trigger the another layout in the parent in a way that you run > layout forever (a "layout loop"). In Flex, because of the LayoutManager > running on frame events, that generally doesn't freeze the UI and I have > seen situations where the LayoutManager never goes idle even though the app > appears to be running fine. There is also the case where the first layout > pass results in scrollbars which causes children to adjust and results in > the removal of scrollbars and that loops forever with the scrollbars > blinking on and off. In Royale, there is a greater chance of hanging. > > Also in Flex, with the LayoutManager, EVERY widget added itself to the > LayoutManager ensuring validation in a particular order, enforcing the > "parents size children
Re: MXRoyale layout issues - questions/discussion
+1 Agree Greg, Layout is the most time consuming issue I faced with UIs I worked although most of them look like very simple. Especially if you do not have any WYSWYG editors. There are lots of thing you have to consider while moving old flex app to royale like 3rd party libraries etc. One less is preferable :) Thanks, Serkan 5.06.2020 13:17 tarihinde Greg Dove yazdı: Yeah I understand this is sometimes necessary Piotr. But the whole point of MXRoyale Flex emulation (and why it does appeal more to some) is that those changes should be much less because it matches more closely to Flex. This is certainly why my client is keen on it. I actually think if they had more time they might be interested in reworking/modernizing the UI, but that is not desirable at this point because it will delay things too much. The app is huge and they need to minimize changes in order to meet their deadlines. Also with MXRoyale, it is not usually a simple css fix for layout, maybe in some simple cases it can be, but mostly not I think, because a lot of MXRoyale layout is driven by code. On Fri, Jun 5, 2020 at 9:41 PM Piotr Zarzycki wrote: 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 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 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. 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 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,
Re: MXRoyale layout issues - questions/discussion
Yeah I understand this is sometimes necessary Piotr. But the whole point of MXRoyale Flex emulation (and why it does appeal more to some) is that those changes should be much less because it matches more closely to Flex. This is certainly why my client is keen on it. I actually think if they had more time they might be interested in reworking/modernizing the UI, but that is not desirable at this point because it will delay things too much. The app is huge and they need to minimize changes in order to meet their deadlines. Also with MXRoyale, it is not usually a simple css fix for layout, maybe in some simple cases it can be, but mostly not I think, because a lot of MXRoyale layout is driven by code. On Fri, Jun 5, 2020 at 9:41 PM Piotr Zarzycki wrote: > 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 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 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. > >> > >> 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 > 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
Re: MXRoyale layout issues - questions/discussion
Hi Alex, thanks for the detailed explanation and offer to take a look, for now some quick replies inline please add questions in the github issue if you want more details about anything I did so far. thanks Greg On Fri, Jun 5, 2020 at 6:50 PM Alex Harui wrote: > Greg, > > I think this thread got forked somehow. If you have a simple test case I > can try to look at it this weekend. > > Thanks. I added issue #849 [1] which should give you something to look at. I suggest you open the Flex build in a browser and then compare things to it in Royale. There are 2 royale builds as well with the same code in the other 2 zips. One without the modifications to MXRoyale and one with. The 'one with' zip also has the modified MXRoyale files, so you should be able to drop them in and overwrite in your local MXRoyale and build to test/review/change what I did. I'm the first to admit that I do think it doesn't feel right. But so far at least it does make a bunch of code work in one app with a lot of deeply nested layouts that was not working before. It certainly does not make everything work. But it helps quite a bit. Certainly appreciate any review/consideration. I am really keen to collaborate on a solution that makes sense for most here. I don't doubt that the changes you propose work for you, but they make me > nervous although I'm not the best at reading code and understanding what it > does. Here's a brain dump on layout in case it helps. > > So far they work better 'for me' I agree. But I think you probably know me enough by now to know that if I am confident that I have a contribution that is objectively good (passes unit tests compared with swf is my normal benchmark) then I will add it. Part of the reason I started this discussion is because I feel a bit the same way here. I am still learning this stuff and figuring things out, so I am not pushing it because I don't want to inflict anything that is not an objective improvement on others. In terms of describing it, the main thing I think, is that the view checks when layout happens if there was a size change since last time layout ran, or if there was a change in size during the current run. Then there is some somewhat awkward checking to see if the parent might be interested in this because there is some 'sizedToContent' aspect to it (which includes a percentage variation on that check). If we think it is relevant, then request the parent to layout. Is this likely to do it sometimes when it is not needed, I suspect so. But so far it has not caused any problems in the codebase I am working with. I'm also working on the Grid related stuff, but you could probably just ignore that for now and focus only on the BoxLayout stuff. In Flex, parents always size their children. The children probably > shouldn't override that size or if they do they have to be careful that it > doesn't trigger the another layout in the parent in a way that you run > layout forever (a "layout loop"). In Flex, because of the LayoutManager > running on frame events, that generally doesn't freeze the UI and I have > seen situations where the LayoutManager never goes idle even though the app > appears to be running fine. There is also the case where the first layout > pass results in scrollbars which causes children to adjust and results in > the removal of scrollbars and that loops forever with the scrollbars > blinking on and off. In Royale, there is a greater chance of hanging. > > Also in Flex, with the LayoutManager, EVERY widget added itself to the > LayoutManager ensuring validation in a particular order, enforcing the > "parents size children" rule. > > In Royale, I tried to go without a LayoutManager because we started out > targeting IE8 and I wasn’t sure if there were some things that were > exceptions to requestAnimationFrame (like setting text or sizing images). > To this day, I'm concerned that it will create an poor debugging experience > because I think when you hit breakpoints the screen updates. All of those > things need testing before we try a LayoutManager based on > requestAnimationFrame. And then, as I think you mentioned, we have to be > concerned about how much code is going to run if we start running all of > the validation methods. > > On the other hand, I think Royale runs layout too often still because two > property changes can trigger two layout passes. I looked at BoxLayout > which extends LayoutBase which does already watch for > widthChanged/heightChanged/sizeChanged so whatever is the root cause of > your problem may not be triggering the layout pass you want, although the > code paths in LayoutBase.childResizeHandler are there to prevent layout > loops. > > Usually, in Flex, a component didn't change its size in response to user > interaction or data loading, it changed its measured size and called > invalidateSize on itself and its parent. The LayoutManager measured > children before parents, then layed out parents before children. > > Yea
Re: MXRoyale layout issues - questions/discussion
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 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 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. >> >> > 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 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 >>> >>> >>> 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 th
Re: MXRoyale layout issues - questions/discussion
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 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.
>
> 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 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
>>
>>
>> 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);
>> widthB
