I would much rather we decide on an implementation. It makes documentation much easier. I'm all for options, but making fundamental things like geometry have options seems like it would make Royale seem more complex.
I would not worry about performance until it actually proves to be a problem. Clearly, most of our examples do not read x/y/width/height at all or very often otherwise we'd have many more layout issues. Most of the UI widgets are designed to let the Browser do the layout. So, of only a small percentage of the UI widgets need x,y,w,h, then it is unlikely to affect performance. Also on the JS side we do have the option of overwriting code if we need to for folks using transforms and SVG. People will be porting their Flex apps where they have x,y,width,height expectations. Even if it costs a little bit more, it seems like in the few places they really need it, it should work like it did in Flex. My 2 cents, -Alex On 2/8/18, 6:50 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: >Seems more reasonable, since its optional and people wanting it can >include... > >2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > >> 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 >> > >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a7234de6a23f08 >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653698261760287 >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0 >> > >> > >> >> >> -- >> >> Piotr Zarzycki >> >> Patreon: >>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a723 >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365369 >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8uMk%2BaMwUG%2BLmY%3D&rese >>rved=0 >> >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a723 >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365369 >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8uMk%2BaMwUG%2BLmY%3D&rese >>rved=0>* >> >> -- >> Carlos Rovira >> >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a7234de6a23f08 >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653698261760287 >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0 >> >> >>
