In most cases we do output the most basic code. But let's look at one scenario I expect to run into more than once, which is placing a popup somewhere.
Like I said, in most of our code, we rarely read back x and y. I don't even think we read x and y in an absolute positioning container. But I would imagine there is a fair number of places in existing Flex apps that do something like: // center tooltip horizontally Var tt:FancyToolTip = new FancyToolTip(); ... tt.x = MyWidget.x + MyWidget.width / 2. This simple example does not work today. I am proposing it should work for non-transformed UI. I think we can make it work. We can provide alternative ways of doing it by abstracting the calculation into utility functions but it just seems strange to me that UI widgets should not have x,y properties that work like they do in Flex/Flash. But you are right, we do have the option of not having x,y on our UI widgets. Another scenario may be as we write more effects. They may have similar issues picking starting points. I think this might be an issue of how easy we make it for folks to migrate. The calculation for x and y is just subtracting the container's offsetLeft or offsetTop from the component's offsetLeft or offsetTop so one extra read of a property. Of course, I could be wrong about that. My 2 cents, -Alex On 2/8/18, 10:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: >Hi Alex, > >in this case it's hard to prove this will be a problem. Maybe the apps >will >suffer it very slightly for most people to perceive it, but that's not the >problem. The problem is our solution will have additional calculations >*always* that other frameworks doesn't have. And that's goes against our >principle in JS to output the most basic js code we can since we'll end >with some strange code only introduced to match a developer time way of >doing things. > >So for that reason I think most people on this thread are saying this is >not a good idea and we should rethink it before make it real. > >just my 2... > >Carlos > > > > >2018-02-08 18:55 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > >> 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%7C71f1da39c0a84d5a8d88a67b23c3 >> 0bf4%7C0%7C0%7C6365369 >> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8 >> uMk%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%7C71f1da39c0a84d5a8d88a67b23c3 >> 0bf4%7C0%7C0%7C6365369 >> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8 >> uMk%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 >> >> >> >> >> >> >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cf68e35ff51fb43d848cd08d5 >6f24209a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537123326111877&s >data=1iLsAJVgE1mg2XxRJm3wNR2TM0AemOVXay14wBjbBMI%3D&reserved=0
