RE: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

; Sent: Monday, November 7, 2016 7:19 AM To: dev@flex.apache.org<mailto:dev@flex.apache.org> Subject: Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite) On 11/6/16, 9:33 AM, "yishayw" <yishayj...@hotmail.com> wrote: &

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Done. -- View this message in context: http://apache-flex-development.247.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56330.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

e-flex-development.247.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56305.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

these entails. -- View this message in context: http://apache-flex-development.247.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56299.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

this message in context: http://apache-flex-development.247.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56299.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

One more thing. I found out that, due to a compiler bug on the JS side, we've gotten away with having the element() and createElement() calls be of type IFlexJSElement in UIBase but WrappedHTMLElement in the subclasses. Yes, I plan to allow this kind of overloading someday, but in theory, it

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

OK. Cross your fingers. Let me know if you run into issues. The HTML folder should now contain wrapped Sprites. Note that several files got moved from Core and Graphics to HTML because we had to move UIBase to HTML and Basic so there would be a wrapped and unwrapped version and once you move

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Sounds good. Looking forward! On Nov 2, 2016, at 8:44 AM, Alex Harui wrote: > Update: > > Maven and Ant builds work locally for me. DataBindingExample runs. > > I will push it tomorrow unless someone comes up with a good reason not to. > > Thanks, > -Alex >

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Update: Maven and Ant builds work locally for me. DataBindingExample runs. I will push it tomorrow unless someone comes up with a good reason not to. Thanks, -Alex

Re: [FLEXJS] Colors (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

On 10/28/16, 2:52 AM, "Harbs" wrote: >There’s two ways to represent RGB with alpha as a uint: > >AARRGGBB (or 0xAARRGGBB) >and >RRGGBBAA (or 0xRRGGBBAA) > >The two quite obviously have very different numeric representations. > >The standard for HTML is RRGGBBAA. Right,

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Hi Alex, thanks for the explanation. regarding integration branches, the main concept it *not break develop* (and of course master ;)). So before Harbs response, I was worried that this merge could cause some days of broken builds (maven, ant, etc...) for that reason is important to make this

Re: [FLEXJS] Colors (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

There’s two ways to represent RGB with alpha as a uint: AARRGGBB (or 0xAARRGGBB) and RRGGBBAA (or 0xRRGGBBAA) The two quite obviously have very different numeric representations. The standard for HTML is RRGGBBAA. On Oct 27, 2016, at 6:05 PM, Alex Harui wrote: > > > On

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

On 10/27/16, 12:56 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: >Hi, > >don't know how you plan to do this, but seems an important refactor and >lots of files included. >I suggest to do this in an

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

On 10/27/16, 12:15 AM, "Harbs" wrote: >I had an idea last night: > >Instead of having two different namespaces for wrapped and unwrapped >components, what about making it a compiler option? Actually, it appears that we can have two SWCs with the same namespaces. The

[FLEXJS] Colors (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

On 10/26/16, 11:59 PM, "Harbs" wrote: >There’s also an issue that Flash uses ARGB, while the default in browsers >seems to be RGBA. > >I think simply avoiding uint representations of RGBA is the simplest >solution… Not quite sure what you mean by that. Are you

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Ok, As a base thinking, and taking into account I didn't gave the cycles you all invested in it, I should notice that FlexJS is not Flash anymore. Is something that could output various things. One of them are SWF, and other is HTML, but we could output more some day. Maybe even FlexJS is not an

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Hi Carlos, The refactor was already done, and I’ve been working off the sprite-refactor branch for a few months already. I’ve been regularly merging the changes from develop into that branch. There is however, a lot of work done on the sprite-refactor branch which has not made it into develop.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

Hi, don't know how you plan to do this, but seems an important refactor and lots of files included. I suggest to do this in an "integration" branch to manage all posible colateral issues generated. And then as adjusted merge with develop. As well, I came to the discussion too much late so I

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

There’s also differences related to events and the like, but we can add blocks for that as well. On Oct 27, 2016, at 10:15 AM, Harbs wrote: > I had an idea last night: > > Instead of having two different namespaces for wrapped and unwrapped > components, what about

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

I had an idea last night: Instead of having two different namespaces for wrapped and unwrapped components, what about making it a compiler option? The primary difference between the two is: 1. The base class is different. 2. References in platform-specific code to the platform-specific

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/26/16, 11:51 PM, "Harbs" wrote: >I don’t need it now that we changed our code. I added the check because I >thought other might be bitten by the same issue. > >If we remove the check, I’m not going to add another class. I do envision "debug-mode" beads and classes

Re: [FlexJS] HTMLElementWrapper extending Sprite

There’s also an issue that Flash uses ARGB, while the default in browsers seems to be RGBA. I think simply avoiding uint representations of RGBA is the simplest solution… On Oct 27, 2016, at 9:43 AM, Alex Harui wrote: >> This code works in Flash because it supports argb. I

Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

I've been looking at the differences between develop and refactor-sprite and how to manage the fork of the Basic set into both a wrapped and unwrapped set. I found that I can just copy the HTML folder to a Basic folder and you can use --follow on the copies to follow history in the fork. In

Re: [FlexJS] HTMLElementWrapper extending Sprite

I don’t need it now that we changed our code. I added the check because I thought other might be bitten by the same issue. If we remove the check, I’m not going to add another class. On Oct 27, 2016, at 9:43 AM, Alex Harui wrote: > > Every bit of code costs in CPU and

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/26/16, 10:41 PM, "Harbs" wrote: >Sure, components should try and validate their values, but client code is >not necessarily components, and it’s pretty easy to introduce a bug where >client code supplies a wrong value. IMO, if you are using typed ValueObjects you

Re: [FlexJS] HTMLElementWrapper extending Sprite

Sure, components should try and validate their values, but client code is not necessarily components, and it’s pretty easy to introduce a bug where client code supplies a wrong value. I do a lot of loading of content programmatically. This includes things like colors. The dynamic content does

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/26/16, 1:01 PM, "Harbs" wrote: >Maybe we can have a compiler option to rename properties that are not >wrapped in platform-specific code? Possibly. We'll see how often such an issue comes up as the tool chain evolves. A key point to keep in mind from this thread

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/26/16, 12:59 PM, "Harbs" wrote: >Pretty likely. The color values can come from anywhere. We happened to >have the values coming from compiled code (so compile-time checks could >have caught that case), but other colors in our app are created at >runtime. > >Runtime

Re: [FlexJS] HTMLElementWrapper extending Sprite

Maybe we can have a compiler option to rename properties that are not wrapped in platform-specific code? On Oct 26, 2016, at 8:43 PM, Alex Harui wrote: > For sure, > if you unwittingly try to add a buttonMode property to a UIBase subclass > you'll find out that the underlying

Re: [FlexJS] HTMLElementWrapper extending Sprite

Pretty likely. The color values can come from anywhere. We happened to have the values coming from compiled code (so compile-time checks could have caught that case), but other colors in our app are created at runtime. Runtime colors seems like a likely scenario. On Oct 26, 2016, at 8:43 PM,

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/25/16, 12:40 PM, "Harbs" wrote: > >My opinion comes from a lot of frustration related to the subclassing. If >you can fix all that and prove me wrong, I’m a happy camper… ;-) I want to set expectations properly. There might be some usability trade-offs or rough

Re: [FlexJS] HTMLElementWrapper extending Sprite

I forgot to respond to this earlier. Some inline responses: > What is the logic behind that statement? The wrapping object is an > EventDispatcher. Each EventDispatcher eats up some 40 bytes. I forgot about EventDispatcher. I was thinking it’s a simple object. You’re right. There is a memory

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/23/16, 5:17 AM, "Harbs" wrote: > >On Oct 21, 2016, at 10:12 PM, Alex Harui wrote: > >> >> >> Carlos is working on an MDL set. We want to make sure FlexJS can handle >> more than one set. We don't have to all work on one set. > >There’s a

Re: [FlexJS] HTMLElementWrapper extending Sprite

On Oct 21, 2016, at 10:12 PM, Alex Harui wrote: > > > Carlos is working on an MDL set. We want to make sure FlexJS can handle > more than one set. We don't have to all work on one set. There’s a difference between specific components based off the basic architecture, and

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/21/16, 3:26 AM, "Harbs" wrote: >Let’s see if I can do a better job at explaining myself. > >> Seems like that would just stomp on the current basic set. > >Yes. And I think that’s appropriate for now. > >When I say default, I mean that we should have one set of

Re: [FlexJS] HTMLElementWrapper extending Sprite

Let’s see if I can do a better job at explaining myself. > Seems like that would just stomp on the current basic set. Yes. And I think that’s appropriate for now. When I say default, I mean that we should have one set of components that we’re all working on for now. We all have limited time,

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/20/16, 9:49 AM, "Harbs" wrote: >I feel like we’re not communicating. No. I want to merge as-is. I don't understand how that would create a second component set. Seems like that would just stomp on the current basic set. > >I think that wrapping should be the

Re: [FlexJS] HTMLElementWrapper extending Sprite

I feel like we’re not communicating. No. I want to merge as-is. I think that wrapping should be the default for all components. I feel that having Flash properties leaking though is worse than a bit of redirection for 99% of use cases. I can’t stress how much of an issue that the Flash

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/20/16, 8:30 AM, "Harbs" wrote: >Can we just merge the sprite-refactor now and deal with the alternates >later (if it’s necessary)? The longer we take to merge it in, the more >work it will be to do so. I assume you mean merging after moving the wrapping code into

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/20/16, 8:23 AM, "Harbs" wrote: >I don’t think so. (unless I’m misunderstanding you) > >I’m not sure it makes sense to have automatic overloading. Requiring >specifying “override” when overriding a function is a good feature. It >makes sure you don’t do it by

Re: [FlexJS] HTMLElementWrapper extending Sprite

Can we just merge the sprite-refactor now and deal with the alternates later (if it’s necessary)? The longer we take to merge it in, the more work it will be to do so. On Oct 20, 2016, at 5:15 PM, Alex Harui wrote: > But if there are advantages to wrapping the SWF side

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/20/16, 1:48 AM, "Harbs" wrote: >AFAIK, properties cannot be overridden as getters and setters, so even >simple properties can have issues. Yes. Rect Point and Matrix were all >classes which caused problems. This is true for now, but this is what I want to look

Re: [FlexJS] HTMLElementWrapper extending Sprite

AFAIK, properties cannot be overridden as getters and setters, so even simple properties can have issues. Yes. Rect Point and Matrix were all classes which caused problems. Transform is actually quite a bit more complicated than just CSS. For HTML, yes, you probably need CSS3. But for SVG,

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/19/16, 2:16 AM, "Harbs" wrote: >I don’t remember all the conflicts we had. Warnings would have helped >somewhat but not totally. Here’s one example (of many): > >We were using a Sprite Image component, and we needed to migrate to a >FlexJS BinaryImage component.

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/19/16, 8:35 AM, "Josh Tynjala" wrote: >"Despite the fact that we’re putting an emphasis on HTML performance, HTML >objects are wrapped. (I think it’s a completely reasonable approach for >HTML.) This causes none of the HTML APIs to leak through. The same should

Re: [FlexJS] HTMLElementWrapper extending Sprite

"Despite the fact that we’re putting an emphasis on HTML performance, HTML objects are wrapped. (I think it’s a completely reasonable approach for HTML.) This causes none of the HTML APIs to leak through. The same should apply to Flash objects and any other future platforms we might have in the

Re: [FlexJS] HTMLElementWrapper extending Sprite

This should obviously have been Spark instead of Sprite… On Oct 19, 2016, at 12:16 PM, Harbs wrote: > We were using a Sprite Image component

Re: [FlexJS] HTMLElementWrapper extending Sprite

Despite the fact that we’re putting an emphasis on HTML performance, HTML objects are wrapped. (I think it’s a completely reasonable approach for HTML.) This causes none of the HTML APIs to leak through. The same should apply to Flash objects and any other future platforms we might have in the

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/18/16, 10:26 AM, "Harbs" wrote: > >On Oct 18, 2016, at 7:30 PM, Alex Harui wrote: > >> >> >>OK, I think you are describing a different problem. AIUI, you are saying >> that certain APIs cannot currently be overridden or overloaded to take a >>

Re: [FlexJS] HTMLElementWrapper extending Sprite

On Oct 18, 2016, at 7:30 PM, Alex Harui wrote: > > > On 10/18/16, 9:08 AM, "Harbs" wrote: > >>> Why are you objecting to using a tooling workflow to find the potential >>> conflicts of your code against the various platform implementations? >> >>

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/18/16, 9:08 AM, "Harbs" wrote: >> Why are you objecting to using a tooling workflow to find the potential >> conflicts of your code against the various platform implementations? > >Because I don’t think it’s just a tooling problem. > >Basically, you are suggesting

Re: [FlexJS] HTMLElementWrapper extending Sprite

> Why are you objecting to using a tooling workflow to find the potential > conflicts of your code against the various platform implementations? Because I don’t think it’s just a tooling problem. Basically, you are suggesting that there should be tooling to warn the user that certain properties

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 10/18/16, 8:18 AM, "Harbs" wrote: >I’m not sure where this response went… > >On Sep 29, 2016, at 9:15 AM, Harbs wrote: > >> Let’s actually do some profiling so we can see if there’s really an >>issue. >> >> Is there really a difference whether

Re: [FlexJS] HTMLElementWrapper extending Sprite

I’m not sure where this response went… On Sep 29, 2016, at 9:15 AM, Harbs wrote: > Let’s actually do some profiling so we can see if there’s really an issue. > > Is there really a difference whether you have one object whose size is x+y or > two objects where one size

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 9/28/16, 12:21 AM, "Harbs" wrote: >The overhead to swfs seem to me like it’s really minimal. There’s not a >lot of added code for using composition rather than inheritance. Well, at Adobe, we said "the overhead is minimal" so many times in Flex that UIComponent grew

Re: [FlexJS] HTMLElementWrapper extending Sprite

The overhead to swfs seem to me like it’s really minimal. There’s not a lot of added code for using composition rather than inheritance. Improving events is probably something which should be done for the JS side as well, so I’m not convinced that’s a major problem either. Some of the event

Re: [FlexJS] HTMLElementWrapper extending Sprite

Probably time to re-open this debate... As I understand it, there are 3 issues: 1. When migrating code, it is important to where your code is relying on Flash APIs that aren't supported by FlexJS, but if UIBase extends Sprite the compiler will happily let your code make calls to Sprite APIs.

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 8/18/16, 3:40 PM, "Harbs" wrote: > >On Aug 19, 2016, at 12:49 AM, Alex Harui wrote: > >> >> >> On 8/18/16, 2:15 PM, "Harbs" wrote: >> >>> Like I mentioned in the other thread, it’s NOT just an author-time >>> problem. >>>

Re: [FlexJS] HTMLElementWrapper extending Sprite

On Aug 19, 2016, at 12:49 AM, Alex Harui wrote: > > > On 8/18/16, 2:15 PM, "Harbs" wrote: > >> Like I mentioned in the other thread, it’s NOT just an author-time >> problem. >> >> Conflicts in variables and methods will cause Flash runtime errors

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 8/18/16, 2:15 PM, "Harbs" wrote: >Like I mentioned in the other thread, it’s NOT just an author-time >problem. > >Conflicts in variables and methods will cause Flash runtime errors and >override can often not be done properly. Are you saying the override would have

Re: [FlexJS] HTMLElementWrapper extending Sprite

Like I mentioned in the other thread, it’s NOT just an author-time problem. Conflicts in variables and methods will cause Flash runtime errors and override can often not be done properly. The only runtime workaround I can see for that would be to automatically rename the methods and

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 1:14 AM, "Harbs" wrote: >I’m running into lots of issues with the fact that HTMLElementWrapper >extends Sprite. The underlying problem is because all the native Flash >properties and methods are being exposed to the compiler for all >sub-classed objects. >

Re: [FlexJS] HTMLElementWrapper extending Sprite

Add -Dskip-tests=true Sent from my LG G3, an AT 4G LTE smartphone -- Original message-- From: Harbs Date: Thu, Aug 4, 2016 7:45 AM To: dev@flex.apache.org; Subject:Re: [FlexJS] HTMLElementWrapper extending Sprite I’m not sure if my computer needs a restart or if I need to clean

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 8/4/16, 7:27 AM, "Harbs" wrote: >BTW: > >Any reason to not set the positioner in Application? I hit some code that >caused an error because the posiitoner was null. Can't think of any reason not to do that. -Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

BTW: Any reason to not set the positioner in Application? I hit some code that caused an error because the posiitoner was null. On Aug 4, 2016, at 5:25 PM, Harbs wrote: > Ah. I did not notice the update there… > > On Aug 4, 2016, at 5:17 PM, Alex Harui

Re: [FlexJS] HTMLElementWrapper extending Sprite

Ah. I did not notice the update there… On Aug 4, 2016, at 5:17 PM, Alex Harui wrote: > On 8/4/16, 12:35 AM, "Harbs" wrote: > >> We’re getting the following errors now (from the Flash Debugger) when >> trying to build core: >> >> VerifyError: Error

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 8/4/16, 12:35 AM, "Harbs" wrote: >We’re getting the following errors now (from the Flash Debugger) when >trying to build core: > >VerifyError: Error #1014: Class mx.core::IFlexModuleFactory could not be >found. >ReferenceError: Error # 1065: Variable

Re: [FlexJS] HTMLElementWrapper extending Sprite

We’re getting the following errors now (from the Flash Debugger) when trying to build core: VerifyError: Error #1014: Class mx.core::IFlexModuleFactory could not be found. ReferenceError: Error # 1065: Variable _FlexUnitFlexJSApplication_org_apache_flex_core_ApplicationFactory is not defined.

Re: [FlexJS] HTMLElementWrapper extending Sprite

Got it. I guess I didn’t realize that distinction when I started on this. On Aug 2, 2016, at 11:29 PM, Alex Harui wrote: > > > On 8/2/16, 12:51 PM, "Harbs" wrote: > >> If it works (and has better performance), I’m OK with leaving the CSS >> family

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 8/2/16, 12:51 PM, "Harbs" wrote: >If it works (and has better performance), I’m OK with leaving the CSS >family of objects as subclasses of the Flash ones. It looks like you left >UIButtonBase as a wrapper rather than a subclass of SimpleButton. Is that >an oversight,

Re: [FlexJS] HTMLElementWrapper extending Sprite

If it works (and has better performance), I’m OK with leaving the CSS family of objects as subclasses of the Flash ones. It looks like you left UIButtonBase as a wrapper rather than a subclass of SimpleButton. Is that an oversight, or was it done purposely? I’ll let you know if this approach

Re: [FlexJS] HTMLElementWrapper extending Sprite

I forgot to mention: the only casualty of the refactor so far was TextItemRenderer. It was designed to be a default renderer on the Flash side and directly inject a TextField as the item renderer for things like DataGrid. Because a TextField's parent is DisplayObjectContainer but components are

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/30/16, 11:05 PM, "Alex Harui" wrote: >I will probably try to code up the other option and see where >the pain points are. There might be some killer issue. I'd like to avoid >wrapping the CSSShape and friends. Well, I just pushed to the refactor-sprite branch changes

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/30/16, 12:13 PM, "Harbs" wrote: >> In order to get Application to wrap the root, I will have to do more >> mucking in this area. I may add createElement because it lets us >>control >> what gets created as the wrapped element is a more common way. >>Otherwise >> if

Re: [FlexJS] HTMLElementWrapper extending Sprite

Combining multiple responses: >> Okay. I just implemented WrappedShape, WrappedSimpleButton, WrappedSprite >> and WrappedTextField. I hope that helps you. >> >> I did not implement a createElement method because I did not see the >> point. On the HTML side there’s code that’s specific to a lot

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/29/16, 4:07 PM, "Alex Harui" wrote: >Related thought, so I don't forget: It isn't clear that CSSShape and >CSSTextField which are only used in SWF implementations needed to become >HTMLElementWrappers. Or more accurately, that CSSShape, CSSSprite, and CSSTextField

Re: [FlexJS] HTMLElementWrapper extending Sprite

In order to get Application to wrap the root, I will have to do more mucking in this area. I may add createElement because it lets us control what gets created as the wrapped element is a more common way. Otherwise if a subclass wants to create a different element, the superclass will have

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/29/16, 3:41 AM, "Harbs" wrote: >Okay. I just implemented WrappedShape, WrappedSimpleButton, WrappedSprite >and WrappedTextField. I hope that helps you. > >I did not implement a createElement method because I did not see the >point. On the HTML side there’s code

Re: [FlexJS] HTMLElementWrapper extending Sprite

I’m also not understanding what positioner does. Why can’t you get a reference to the parent element from the FlexJS parent? On Jul 29, 2016, at 9:00 AM, Harbs wrote: > Cool. > > I’m not totally getting the use case of the IFlexJSElement, but there’s > definitely

Re: [FlexJS] HTMLElementWrapper extending Sprite

Cool. I’m not totally getting the use case of the IFlexJSElement, but there’s definitely nothing wrong with adding a wrapper class that extends a Flash type. I’d think it should extend DisplayObject rather than InteractiveObject though. On Jul 29, 2016, at 8:34 AM, Alex Harui

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/28/16, 9:58 PM, "Harbs" wrote: >I gave everything a $displayObject property which is an alias to the >specific DisplayObject type. There’s also $sprite $textField $shape and >$button for the specific types. > >I did this to avoid having to do casting all over the

Re: [FlexJS] HTMLElementWrapper extending Sprite

I gave everything a $displayObject property which is an alias to the specific DisplayObject type. There’s also $sprite $textField $shape and $button for the specific types. I did this to avoid having to do casting all over the place. I did not use element because it was a IFlexJSElement and

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/28/16, 2:55 PM, "Harbs" wrote: >It should be creating it in the constructor. Is there a problem with >doing it like that? Not sure. I thought you were going to re-purpose the 'element' property from the JS side. Is there a reason you didn't do that? I think

Re: [FlexJS] HTMLElementWrapper extending Sprite

It should be creating it in the constructor. Is there a problem with doing it like that? On Jul 28, 2016, at 11:51 PM, Alex Harui wrote: > Harbs, > > I've started poking around in this branch. How is the SWF version > supposed to create the wrapped element? I would've

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 1:41 PM, "Alex Harui" wrote: > > >On 7/27/16, 1:27 PM, "Harbs" wrote: The only class which still subclasses Sprite is Application. I don’t know a way around that. >>> >>> One idea is that, since developer code never

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 1:27 PM, "Harbs" wrote: >>>The only class which still subclasses Sprite is Application. I don’t >>>know >>> a way around that. >> >> One idea is that, since developer code never instantiates an Application >> (only the framework does) that Application could

Re: [FlexJS] HTMLElementWrapper extending Sprite

On Jul 27, 2016, at 10:42 PM, Alex Harui wrote: > > > On 7/27/16, 12:20 PM, "Harbs" wrote: > >> Yes. It was a significant change. You can see what I did on the >> “refactor-sprite” branch. >> >> I spent the whole day on this. I just committed the

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 12:20 PM, "Harbs" wrote: >Yes. It was a significant change. You can see what I did on the >“refactor-sprite” branch. > >I spent the whole day on this. I just committed the last change to make >all the projects compile with no errors. (I did not test the

Re: [FlexJS] HTMLElementWrapper extending Sprite

As I understand it, that's why they made it open source. To allow community contributions. - Josh On Wed, Jul 27, 2016 at 11:34 AM, Alex Harui wrote: > > > On 7/27/16, 10:57 AM, "Josh Tynjala" wrote: > > >It's worth mentioning that IntelliJ IDEA

Re: [FlexJS] HTMLElementWrapper extending Sprite

Yes. It was a significant change. You can see what I did on the “refactor-sprite” branch. I spent the whole day on this. I just committed the last change to make all the projects compile with no errors. (I did not test the examples.) I changed 4 base classes: HTMLElementWrapper, CSSShape,

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 10:57 AM, "Josh Tynjala" wrote: >It's worth mentioning that IntelliJ IDEA doesn't respect [Exclude] >metadata. Thanks for that. I wonder if other IDEs handle it. IntelliJ made their Flex support open-source, could we fix that if we need to? -Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

It's worth mentioning that IntelliJ IDEA doesn't respect [Exclude] metadata. - Josh On Wed, Jul 27, 2016 at 10:42 AM, Alex Harui wrote: > > > On 7/27/16, 1:14 AM, "Harbs" wrote: > > >I’m running into lots of issues with the fact that HTMLElementWrapper

Re: [FlexJS] HTMLElementWrapper extending Sprite

On 7/27/16, 1:14 AM, "Harbs" wrote: >I’m running into lots of issues with the fact that HTMLElementWrapper >extends Sprite. The underlying problem is because all the native Flash >properties and methods are being exposed to the compiler for all >sub-classed objects. >