Ok Alex, for what I read, I understand that we already has mechanism in Royale to handle this. So I think Mark, should try to do some easy test case that showcase the problem and he/we can work over that to see the easiest solution. Maybe is just a matter of supporting that in Jewel cause I wasn't aware of that when I implemented that components. As well maybe Marks function proposal could be part of Royale as an utility function to manage conversions between px to em and viceversa and put as easy as possible for people that wants to use it
@Mark, do you want to work on that? Alex and I can support and test over concrete app test and discuss how to go further. One thing I get from Alex's words is that Ems could be problematic at some point due to inconsistencies, while Px seems to have more consistency. Since Apps is a mix of text and drawings, while increasing/decreassing sized Px could give as a better control over different targets/runtimes, while Ems could be problematic. But I don't have clear the right response since all of this is new for me, so maybe we should explore this a bit more to get some final thoughts and rules to go with. Thanks El mar., 15 ene. 2019 a las 19:52, Alex Harui (<aha...@adobe.com.invalid>) escribió: > Hi Carlos, > > In theory, nobody is "forcing" anything in Basic. Hopefully everything is > PAYG. If there is a PAYG way to support "em" in Basic then great. Maybe > having a units var/const is good enough. > > One thing I just thought of is that there is typically a > 'get-what-you-set' rule for Flex properties that would be nice to have in > Royale. And a similar 'set-what-you-get' rule. This makes other things > simpler, such as animations. > > As I mentioned in the "missing", width is read to get the current > displayed width in pixels. In the browser it reads back offsetWidth, > IIRC. Then if you want to run a resize effect, you can just do: > > someDisplayObject.width++; > > or in layouts: > > someDisplayObject.width = someOtherDisplayObject.x; // widen to line > up with left side of other object > someDisplayObject.x = someOtherDisplayObject.width; // horizontally > position first object just after other object. > > This may not do the expected/right thing if the units are ems. > > The more I think about it, it starts to feel like em is more like > percentWidth. These are ways of specifying relative sizes. Width is for > specifying explicit sizes and reading back the current size in pixels. > Percentage is probably easy for us to implement an all future > targets/runtimes. But is 'em' going to be a popular enough unit for us to > want to support it forever on all platforms? > > As I mentioned recently, there are top-down layouts and sizeToContent > layouts. sizeToContent gets broken on occasion and then I fix it when > needed. I just fixed it in the emulation components for Spark TabBar and > ViewStack. There are probably still bugs in it in other components. > > Anyway, percentage is for top-down. You have to know the parent's size > for percentage to make any sense. It looks like 'em' and 'rem' are for > sizeToContent. One article said that 'em' has serious problems when > nested. I don't know if 'rem' was a fad or is the future. But I'm > wondering if we need to support these content- relative units anywhere but > in the CSS. > > That's why I'm wondering where we get stuck in our sizeToContent > scenarios. SizeToContent in Basic is PAYG. Dynamic changes to things is > PAYG. It takes more and more code to handle the various ways things can > change at runtime that affect sizeToContent. The Basic support is just > that, if you haven't specified a fixed size or percent size, then we size > to content but we don't watch for all kinds of changes to content. Other > PAYG code can come in and add more logic to check for other kinds of > changes. It may be that the code we need is the code to detect that the > browser changed the font size and then send layoutNeeded events to the > layouts and/or components. > > By doing that, we are again abstracting away platform/runtime details. > Royale will support changes that affect the size of components that are > sized to content. The app developer may not need to specify "em" other > than in their CSS. That might be a platform-specific way of specifying the > font-size of a component. But regardless of how they specify their font > sizes, if they change the font size at runtime (which they could also do by > altering the CSS font-size in px), Royale components that are sizeToContent > should know how to respond to that (via PAYG code). > > HTH, > -Alex > > On 1/15/19, 4:41 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> > wrote: > > Hi, > > very interesting discussion > > @Alex : My first reaction is that Basic is basic and works in pixels > and > that adding other units can happen in other component sets and beads. > > Although Basic is just Basic, people using it could want to switch > from PX > to EM at sometime. I think it should not be good to force PX in any > part of > Royale > > One thing is clear: we should not have "px" hardcoded in UIBase, so the > const proposal seems ok to me to fix it at UIBase level. If that is ok > for > all we should do it. > > In the other hand, about using "sizeToContent", I only remember to deal > with that method in one Jewel component, so don't know if that is used > "internally" in more parts (without the need for me to deal with it in > the > component) or if I need to do something for each component. But as well > that seems to me like a theory, and maybe you should check if that is > working as you think, for for that you first need to be able to switch > from > PX to EM right? > > I think Jewel could be configured to "em" out-of-the-box, since seems > for > me more "font oriented", and applications are, from my point of view > more > text oriented, since we are showing list of textual item, buttons with > labels, labels (texts) and more... > > @Mark, maybe you could do a PR with your proposal in a form of a > function > class so we can use in the same way we use for example " > org.apache.royale.html.util.addElementToWrapper" > > Thanks > > > > El mar., 15 ene. 2019 a las 1:29, Alex Harui (<aha...@adobe.com.invalid > >) > escribió: > > > Yes, that might be possible as well. We don't really have to pick > one > > strategy. Different component sets can have different strategies. > We > > could have an "all em" set if we wanted. It would be nice to share > code in > > UIBase, but not a requirement. Hopefully, IUIBase doesn't really > presume > > pixels (although it still wants width/height to be a Number), and > hopefully > > we don't have lots of expectations on UIBase instead of IUIBase. > > > > Another way to think about Royale is that our components (really the > > beads) spit little bits of JS, CSS, and HTMLElements into the > browser. So, > > for any website you could build without Royale, you should be able to > > fashion Royale components that automate and encapsulate the building > of > > that site and similar sites. So whatever pattern needs to be added > to the > > final JS/CSS/HTML, we should be able to encapsulate anything that > isn't a > > one-off and provide parameters to tweak the pattern. > > > > My 2 cents, > > -Alex > > > > On 1/14/19, 12:26 PM, "Mark Kessler" <kesslerconsult...@gmail.com> > wrote: > > > > As a comment on the helper functions, we could also just have > > something that does on the fly conversion. In other words if I > say > > 300 pixels, I want it to translate that into EM / other unit in > the > > background. The reason I bring that up is to allow exact PX > still be > > used for the Flex / Air side and converted for the js/css side. > > > > pixelTotal / fontSize = em > > > > 300 / 14 = 21.429 (rounded) > > > > Soo 300px for flex and 21.429 for JS side. > > > > -Mark K > > > > > > > > -- > > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7Ccbd4b3358c804fdf6fce08d67ae6b8cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636831528697393272&sdata=dxt8hMOqR2b2qu6ikYbd%2B4IAUByx0rl9%2BFuniAc0FP8%3D&reserved=0 > > > > Carlos Rovira > > Presidente Ejecutivo > > M: +34 607 22 60 05 > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7Caharui%40adobe.com%7Ccbd4b3358c804fdf6fce08d67ae6b8cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636831528697393272&sdata=dxt8hMOqR2b2qu6ikYbd%2B4IAUByx0rl9%2BFuniAc0FP8%3D&reserved=0 > > > Conócenos en 1 minuto! < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7Caharui%40adobe.com%7Ccbd4b3358c804fdf6fce08d67ae6b8cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636831528697393272&sdata=BTnuc9qYYa%2FrW99aZd0s8pUgZGjVzHKTvfOJxkVNQuA%3D&reserved=0 > > > > > AVISO LEGAL: La información contenida en este correo electrónico, y en > su > caso en los documentos adjuntos, es información privilegiada para uso > exclusivo de la persona y/o personas a las que va dirigido. No está > permitido el acceso a este mensaje a cualquier otra persona distinta a > los > indicados. Si Usted no es uno de los destinatarios, cualquier > duplicación, > reproducción, distribución, así como cualquier uso de la información > contenida en él o cualquiera otra acción u omisión tomada en relación > con > el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor, > notifíquelo al remitente y proceda a la eliminación de este correo > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento > de la > legislación española vigente en materia de protección de datos de > carácter > personal y del RGPD 679/2016 le informamos que sus datos están siendo > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, > con > la finalidad del mantenimiento y gestión de relaciones comerciales y > administrativas. La base jurídica del tratamiento es el interés > legítimo de > la empresa. No se prevén cesiones de sus datos, salvo que exista una > obligación legal. Para ejercitar sus derechos puede dirigirse a > CODEOSCOPIC > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid > (MADRID), o > bien por email a...@codeoscopic.com, con el fin de ejercer sus > derechos de > acceso, rectificación, supresión (derecho al olvido), limitación de > tratamiento, portabilidad de los datos, oposición, y a no ser objeto de > decisiones automatizadas, indicando como Asunto: “Derechos Ley > Protección > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de > datos:d...@codeoscopic.com > > > -- Carlos Rovira http://about.me/carlosrovira
