Hi Peter, I think you are right. Main need is to get AS3/MXML producing great HTML/JS/CSS, and SWF right now is in second place. I think it could be great to demonstrate that we can generate more outputs, but maybe WebASM, swift (iOS) and Java (Android) could be great outputs as well. But for this to happen I think we need first to get more people join us, so I 'd concentrate in get 1.0 with stable HTML/JS/CSS that could let us do a full application. I just talked about this in other thread, but for me is to get Forms /validation working good and having a good looking theme (this implies not only art but a theme infrastructure in Royale).
we need to show people that some demos that looks good and make as easy as we can try us to convince people to try and join, and his final experience will be good in order to join, so SWF for me is not priority right now. Thanks 2017-10-23 15:36 GMT+02:00 Peter Ent <[email protected]>: > I've been debating whether or not to send this, but given this discussion, > I think it is appropriate. > > It is still unclear to me whether or not we code Royale with the priority > on HTML/JS/CSS platform or SWF. Alex and I have talked about this and > primarily the rule is: make it work for HTML/JS/CSS as best as possible > and then get the SWF version to work. > > This is why layouts are pretty lightweight on the JS side because the > browser takes care of things. Not too long ago I made changes to the > layouts to use Flexbox[1] and then made the SWF side work similarly > (although without all of the Flexbox abilities). > > When you want to introduce something like "includeInLayout", it is not > natural to the browser platform. There is not a way - that I know of - to > tell the browser that a particular element should be displayed but not > counted in the layout process. A property like includeInLayout seems as if > it would go all the way down to the UIBase class level which implies that > all layouts would support it. And that means layouts would have to be > completely algorithmic on the browser, bypassing the browser's layout > mechanisms and potentially slowing down the app and increasing the size of > the download - definitely not PAYG. > > The PAYG way would be to introduce an IncludeInLayoutBead bead and then > add VerticalLayoutSupportingIncludeInLayout, > HorizontalLayoutSupportingIncludeInLayout and so forth. You'll note that > to use states requires SimpleStatesImpl since not all apps will use states. > > If I am wrong about being able to display an element and getting the > browser to ignore it for layout, then my point here is moot. I suppose a > CSS float might suffice, but I think that may not get what is really > desired. > > ‹peter > > [1] You can argue, fairly easily, that not all browsers still fully > implement Flexbox and some browsers have trouble with complex or nesting > Flexbox. So perhaps Flexbox wasn't a best choice in all circumstances. But > the point was to get more mileage out of the browser and keep the download > small. > > On 10/19/17, 4:02 PM, "Piotr Zarzycki" <[email protected]> wrote: > > >Hi Guys, > > > >I'm trying to understand how states are working. I have simple code which > >should actually work. I'm using latest FlexJS from develop - not Royale > >yet. [1] Am I doing something wrong ? > > > >Can someone shed some light how internally States are working ? I would > >like to debug things, but not sure where to start. > > > >I have to admit that DataBindingExample where states has been used working > >fine in old FlexJS code and Royale. > > > >[1] > >https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fpaste.apa > >che.org%2FVBTs&data=02%7C01%7C%7Ccdb0ded139084900f09b08d5172c > 674a%7Cfa7b1b > >5a7b34438794aed2c178decee1%7C0%7C0%7C636440401835413777& > sdata=fDTsTEb9iVGb > >Y2BqsAElhSm7ZrO%2Bb4%2FQa5Oy1ukX%2BH0%3D&reserved=0 > > > >Thanks, > >Piotr > > -- <http://www.codeoscopic.com> Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com Conocenos Avant2 en 1 minuto! <https://avant2.es/#video> Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
