@Alex - yeah, I was just curious if there could be a sneaky way to keep it
to the single level. If not, then so be it.
That was only for the UIGraphicsBase class, which I was pretty much using
like 'flash.display.Shape' for testing.

Anyhow, the Graphics emulation can be used with anything that implements
this:

https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Graphics/src/main/royale/org/apache/royale/display/IGraphicsTarget.as


Just thinking about it, that should be SVGSVGElement and not simply
SVGElement for the JS version on line 36. I will change that tomorrow.

So if a component view implemented its own version of the above interface
and supplies the SVG element as render target, then it doesn't actually
care where that internal svg is (child 0 or otherwise) - that is the view
component's problem.
I did also consider a future enhancement where the IGraphicsTarget instance
could have a 'graphicsBoundsChange' event dispatched (from itself) on a
frame update if the graphics bounds changed. This could be toggled on the
Graphics instance itself so it only happened if needed. But that is not
done at this point.... and also that could be added only if there is demand
for it, I think.



On Wed, Jan 29, 2020 at 5:37 AM Alex Harui <[email protected]> wrote:

>
>
> On 1/28/20, 1:01 AM, "Carlos Rovira" <[email protected]> wrote:
>
>     Hi again :),
>
>     I still didn't see the code, but was imagining how I'd like to use this
>     feature.
>
>     Some thoughts:
>
>     1.- Could be possible to have it as a bead for UIBase components a
> side of
>     the UIGraphicBase that could still be convenient for some cases?
>
> Disclaimer:  I haven't written the code or looked at it, so this is just a
> high-level opinion:  Regarding a bead for UIBase, I think it would depend
> on how the "child 0" problem gets solved.   My reason for posting is to
> remind folks that in theory, the Basic Containers already support an
> internal container.  I haven't found a lightweight way of enabling internal
> containers, mainly because I didn't want to mark the children and compute
> or track the set, but also because since it is currently used for "chrome"
> (Panel TitleBar), it is relatively simple to enable it the way it is.
>
> Also, MXRoyale's UIComponent is essentially as heavy as a Basic Container,
> and Spark Skinning emulation supports a separate child Skin.  Other
> component sets could just start out being heavier if they want to quickly
> enable this new library via a bead.
>
> Of course, I could be wrong...
> -Alex
>
>
>

Reply via email to