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 <piotrzarzyck...@gmail.com>
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 <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>*
>
