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
