I personally prefer having Bead for such things. 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yishayj...@hotmail.com>:
> I agree, that’s why I’m proposing to have a bead do the calculation. If > you care about integrity with actual position on the screen and are willing > to sacrifice some performance use ScreenPositionCalculatorBead, otherwise > use the default which is more performance oriented. > > Another option is to just use a utility function for calculating that > actual screen position when necessary. The util function can get the > element using (component as IRenderedObject).element and then do whatever > DOM/flash/wasm queries you need. > > From: Carlos Rovira<mailto:carlosrov...@apache.org> > Sent: Thursday, February 8, 2018 12:33 PM > To: dev@royale.apache.org<mailto:dev@royale.apache.org> > Subject: Re: What is x and y? What is width and height? > > I don't have right now a proposal for this, but it seems to me that > introduce calculations that affects performance will be a bad idea. That > will make us not elegible for some escenarios/people. On e of the things I > like from Royale is that in the end we are outputting the most easy code > while we are making it easy for coders through MXML/AS3. > I think we should look the problem in other perspective to avoid impacts in > performance > > 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yishayj...@hotmail.com>: > > > 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 > > >>> > > >> > > > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
