HI Carlos, You might be describing a different problem than I originally thought.
Besides the issue of sizedToContent vs "sized by parent", there is separate problem where, early in the lifecycle of some components, you can't get the browser to tell you the width/height of the component. I see some other uses of requestAnimationFrame in the Royale code. It may be that someone handled a similar problem the same way. I'd be afraid that with a timer/frame the user might see the UI for a split second in its ugly form then snap into place. I've been lucky enough to find other solutions, but I'm not going to guarantee there is always some other solution. Regarding your topics, I'm not sure we can guarantee only one way of dealing with children. It really should be up to the component set. In a truly basic app, there shouldn't need to be any visiting of children by the layouts. It really should just be creating HTMLElements, setting attributes including display="flex", etc. It shouldn't require other code. But other component sets might, and MXRoyale for visits every child and uses sizeChanged. I would think sizeChanged would be best for most component sets, but maybe layoutNeeded will work. layoutNeeded is primarily intended for the beads to talk to a layout in the same components. It is occasionally used to kick off a layout in some other component based on an event. It might be that some other event gets sent to each child to say "hey, you should now have a valid size". It probably depends on what width="100%" means in your app/component set. In MXRoyale, it does not mean what it would in CSS so the styles.width is not set to 100% and the old Flex layout runs and assigns a number instead. And thus sizeChanged is sent. Maybe you can explain what 100% means for Jewel DG and what component needed an actual number. HTH, -Alex On 3/14/20, 4:57 PM, "Carlos Rovira" <[email protected]> wrote: Hi Alex, I did some research already during last weeks a spend many hours trying things. Some things I did: 1.- Layouts (for now the 4 horizontal and vertical main layouts) that are the most used, since are in Cards, HGroup, VGroup,..., loop over the childs and send "layoutNeeded" event. (In the second DG TDJ example I put an slider to change the card height, and the inner DG with height="100%" works as expected, but all thanks to the "requestAnimationFrame" loop that waits for the height. For this to work you need to set the parent Card height to some concrete pixel height. Then DG can be height="100%" I would want to make this work removing the "requestAnimationFrame" hack. 2.- I think the same could be applied to width="100%" as well based on the loop hack from 1.- and setting parent Card width to a fixed width. 3.- Maybe nesting some containers with the first to fixed h or w, but the rest chain of components to 100%, could not work. Still untested. 4.- After the recent email from Piotr in the other Jewel DG thread, I think we need some convention on how to operate always with the two main events: * sizeChanged * layoutNeeded We should have clear a metodology for all components (Card, HGroup, DataGrid,...whatever). Should we layouts dispatch layoutNeeded on childs? or instead "sizeChanged"? or both? I think this is important If we make some algorithm that make us "industrialize" how we should implement always the same, I think that would be what all want. 5.- To get proper width and height (real pixels) if we have percentage w o h: Maybe we should implement some internal code that ensure this at UIBase (or even up in the hierarchy), or in LayoutBase. At the end we need to ease those values to the user when "layout()" (in a component's layout ) run. IOW, if we do at the start of the layout method ´trace(host.width)", we should get the right value, no matter if they are using pixel or percent values. Let me know if you agree with these exposed points. Thanks Carlos El sáb., 14 mar. 2020 a las 17:46, Alex Harui (<[email protected]>) escribió: > Hi Carlos, > > I've been looking at the number of times the AdvancedDataGrid gets layed > out in an example from Serkan. That helped me propose this event change. > > I see a few other things as well. As I mentioned on some thread recently, > the view and layout have to consider several scenarios: > > 1) sized to content > 2) sized by parent > > And for ADG: > 3) no data provider > 4) empty data provider > 5) data provider set later (usually by server results) > > And probably some more. I'm still looking into it. I don't have a > proposal yet, but my first thought was that the View should be responsible > for the intelligence that blocks layout passes until the last possible > event. I think layouts are much more re-usable so they shouldn't carry > that logic. The View can determine, for example, that the component has a > percentage height/width and thus know that until there is a sizeChanged > event, skip all other attempts to layout. But as I mentioned elsewhere, > that may mean that some of our layouts will need to visit each child. This > already happens in the MXRoyale set because the MXRoyale code is running > old Flex layouts in absolute positioning because we want to override > browser layouts, but isn't true in Basic. Some layouts set display="flex" > and the browser does the work and there is no loop to visit each child to > send a sizeChanged event. > > Let's get through this event change first, and hopefully I'll have time to > further optimize ADG, and then I might have time to dig through the Jewel > DG. But if you have time to do the analysis yourself, I think you want to > try to understand the "why" for the various layout passes and see if you > can build in some intelligence around which passes are important in various > scenarios. > > HTH, > -Alex > > On 3/14/20, 3:40 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Alex, > > don't know of code that would break, but I think that would be the > right > thing to do. So better fix to comply with that change. > > What I'm more concern is about getting the pixel width or height when > sizeChanged or layoutNeeded are thrown from layouts. > As I stated before in other thread I had some issues, and yesterday > Piotr > reported another issue in DataGrid when width="100%" (or any other > percentage). I could "hack" height using low level js > requestAnimationFrame, but don't know how to fix percentage width > problems. > > I don't find any way to make calculations in Royale to get the real > pixel > width value when a component has width set to some percentage value. > The > only way I'm seeing right now is to make some js low level hack with > calc(% > -px) in style.width. I think now that we have some infrastructure and > examples with Cards, HGroups/VGroups, and more, is a good time to have > some > easy way to get to the layout() method (or other handler) and get > directly > width or height instead of 0 in the case we are using some % value. > > Now that I have to work on the fix for Piotr, what do you think about > to > take you a look and see that real case problem? Piotr committed > yesterday > that DataGrid example to TDJ. If you want we can work over it together > and > try what you think it could be a good option. > > Would be that possible? > > Thanks > > Carlos > > > > > El sáb., 14 mar. 2020 a las 6:12, Alex Harui (<[email protected] > >) > escribió: > > > Hi, > > > > I am wanting to change the way UIBase setWidthAndHeight dispatches > its > > events to cut down on the number of layout passes. > > > > Right now, if you change both the width and height of a component, > you get > > 3 events (widthChanged, heightChanged, sizeChanged). I want to > change that > > so that you only get sizeChanged. This change would cause the > "meaning" of > > widthChanged to mean that only the width changed during a resize so > you can > > optimize some of the layout code and similar for heightChanged. > And thus, > > you will only ever get one event out of setWidthAndHeight, it will > either > > be: > > > > - "widthChanged" meaning that only the width has changed > > - "heightChanged" meaning that only the height has changed > > - "sizeChanged" meaning that both width and height have changed > > > > Does anyone know of any code that would break if we made this change? > > Everywhere I look, code listens to all 3 and does not react > differently so > > sometimes lays out 3 times, often once before the height has changed. > > > > Thoughts? > > -Alex > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7d15591c140d40b0cd6408d7c8738509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637198270791841156&sdata=r0%2BRdiWCj6ECXB1GZ%2F6BHIIDfgmRcDG5bzIYK3Aj2G8%3D&reserved=0 > > > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7d15591c140d40b0cd6408d7c8738509%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637198270791851158&sdata=ZXNr4GK5Yx6o%2BT21l%2Fu4b5K%2Br2qQPdMZ6SmF%2B7zZAag%3D&reserved=0
