Mainly for the record, the only other implementation that came to mind (and I
rejected) was to track marked things. Something like:
/** add a child */
public function addElement(element:IUIBase);
/** add an internal child */
public function addInternalElement(element:IUIBase, elementType:String)
{
internalElements.push({ element: element, elementType: elementType);
addElement(element);
}
private var internalElements:Array= [];
/** get number of children */
public function get numElements():int
{
return super.numElements - internalElements.length;
}
It would duplicate every IParent API: getElementAt, getInternalElementAt, for
example. But what I didn't like was that getElementAt would have to check the
internalElements and not count elements in that array which would be slow.
There are variants to that strategy where you track childElements and consider
everything else internal, but I still think that requires filtering on the
calls most used by application developers. The current implementation also
duplicates the APIs, but because the application developer's children are all
placed on an internal container, there isn't any filtering.
Of course, I could be wrong...
-Alex
On 1/28/20, 8:40 PM, "Greg Dove" <[email protected]> wrote:
@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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FGraphics%2Fsrc%2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Fdisplay%2FIGraphicsTarget.as&data=02%7C01%7Caharui%40adobe.com%7C8b0de029d5d44c35209908d7a4755cc6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637158696282111863&sdata=ruaKX6uEWmIPPwpxjKcoCVF1u3CLX%2FF8l8TD2YOJfnY%3D&reserved=0
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
>
>
>
