How about using beads that implement IPositionCalculator. UIBase won’t return x and y directly but use a bead to calculate them. The default SimplePositionCalculatorBead would return x and y based on the setter while the ScreenPositionCalculatorBead would return the values based on DOM access.
From: Gabe Harbs<mailto:harbs.li...@gmail.com> Sent: Wednesday, February 7, 2018 6:24 PM To: dev@royale.apache.org<mailto:dev@royale.apache.org> Subject: Re: What is x and y? What is width and height? FWIW, I do think we need a “constrained layout” which places *everything* absolutely and does not rely on browser layout. If that layout were to be used, the bounding box values would be correct. > On Feb 7, 2018, at 6:00 PM, Peter Ent <p...@adobe.com.INVALID> wrote: > > I think I agree with Harbs about x,y,width,height just returning the set > values if the calculation would be expensive. I wonder what the > circumstances are that we actually need to have precise values in > calculations. For example, if I wanted to make a circulate layout, how > would I go about doing that? > > In the places I've done layouts without regard to platform I'm just > assuming things work. For example, in the DataGridLayout, I need to > transfer the column width given on the js:DataGridColumn definition to > both the List (column) and the corresponding Button in the ButtonBar. > Ideally, the browser takes that (along with display and position styles) > and just does the right thing with minimum code on our part (that's not > actually what I'm doing, so perhaps I should rethink that one more time). > > ‹peter > > On 2/7/18, 8:35 AM, "Gabe Harbs" <harbs.li...@gmail.com> wrote: > >> The offset values are very expensive. >> >> They are also not completely accurate. I¹ve found it¹s difficult to get >> accurate values where SVG and transforms are in play. >> >> I would suggest that x,y,widht and height should reflect *set* values >> even if they are not always the actual ones. >> >> For cases where it¹s necessary to get accurate measured x,y,width and >> height, I would suggest using ³measured² variations of these values, or >> better, a getMeasuredBounds() method. >> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <aha...@adobe.com.INVALID> >>> wrote: >>> >>> Hi, >>> >>> In Royale on JS, we are trying to leverage the browser's layout code as >>> much as possible. We only run our own layout code in a few places. >>> In debugging a few layout issues I discovered that UIBase is not >>> reporting >>> x and y the way we expect it from Flex/Flash. Browser elements don't >>> have >>> x and y properties, instead they have offsetLeft and offsetTop. Mainly >>> for backward-compatibility with Flex/Flash, Royale has had x and y in >>> the >>> API since the beginning. I think it is a bug that x and y do not act >>> like >>> they do in Flex and plan to fix that after this release. Thoughts? >>> I'm a >>> bit concerned of the expense of calculating x and y because you have to >>> check if the offsetParent is your immediate parent and get the >>> offsetLeft/offsetTop of the immediate parent, but I think that's what it >>> would take to fix it. >>> >>> Similarly (well, sort of), Flex did not support CSS margins, only >>> padding. >>> The browser reports width (offsetWidth) as factoring in content, padding >>> and borders, but not margin. I think that's right, and matches Flex. >>> However, our custom layout algorithms do not currently factor in margins >>> since they are not reported in width. I think our custom layout should >>> request width and margins and do the math. We should not change width >>> to >>> include margins. Thoughts? This will make our custom layout code a bit >>> more expensive as well as it will probably need to call >>> getComputedStyles() on all of the children in order to get margins. >>> This >>> is also something to fix in the next release. >>> >>> Of course, I could be wrong. Thoughts? >>> >>> -Alex >>> >> >
