On 7/27/16, 11:03 PM, "Harbs" wrote:
>The other piece of this is stage.getObjectsUnderPoint.
>
>It would be nice to wrap that as well. The question is where to do that.
>HTMLElementWrapper as well? What about getting global objects? There’s no
>“stage” is there?
IMO, hitTestPoint and getObject
The other piece of this is stage.getObjectsUnderPoint.
It would be nice to wrap that as well. The question is where to do that.
HTMLElementWrapper as well? What about getting global objects? There’s no
“stage” is there?
On Jul 28, 2016, at 8:58 AM, Harbs wrote:
> Any suggestions on how to imp
Any suggestions on how to implement this?
Should we just add a hitTestPoint function to HTMLElementWrapper that behaves
like the Flash version?
I’m not sure what to do about the shape flag. I think the HTML version takes
shape into account automatically.
On Jul 28, 2016, at 8:46 AM, Alex Harui
On 7/27/16, 10:40 PM, "Harbs" wrote:
>I just found this:
>http://stackoverflow.com/questions/8813051/determine-which-element-the-mou
>se-pointer-is-on-top-of-in-javascript
>
>Seems pretty straight-forward.
That points to [2], which has the following snippet:
"If the specified point is outside
I just found this:
http://stackoverflow.com/questions/8813051/determine-which-element-the-mouse-pointer-is-on-top-of-in-javascript
Seems pretty straight-forward.
On Jul 28, 2016, at 8:38 AM, Alex Harui wrote:
>
>
> On 7/27/16, 10:34 PM, "Harbs" wrote:
>
>> Is there some equivalent to hitTes
On 7/27/16, 10:34 PM, "Harbs" wrote:
>Is there some equivalent to hitTestPoint in FlexJS?
>
>I need to find an object under a mouse event location. Is there something
>already, and if not, any suggestions on how to go about implementing it?
AFAIK, we haven't done anything for that. Is there a
Is there some equivalent to hitTestPoint in FlexJS?
I need to find an object under a mouse event location. Is there something
already, and if not, any suggestions on how to go about implementing it?
Harbs
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 be an interface. The
>>
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 last change to make
>> all the projects comp
Lastly Chris, after running through the maven build steps, I then built
using 'ant all' inside flex-asjs (which completed fine), then started to
follow the maven build sequence again after that.
Compiler and typedefs seemed fine, but I got a face-full of rat on the
framework build.
I added:
temp
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 examples.)
>
>I changed 4 bas
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 doesn't respect [Exclude]
> >metadata.
>
> Thank
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, Butto
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
Hi Chris,
I wasn't suggesting to remove the rat support, I can see for sure how that
would be useful, I just didn't know how (yet) I needed to address the
issues I had.
I just followed the instructions on a fresh setup and the build completed
fine for the 3 main parts.
I did see this in the comp
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
> >extends Sprite. The underlying problem
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.
>
>For my port this is causi
Copy/pasting from several posts...
On 7/27/16, 2:09 AM, "Harbs" wrote:
>Thinking about this some more, I think an svg should have a different API.
>
>SVG elements should inherit from UIBase and have the full capabilities
>For one, I’m not sure primitives should implement beads. UIBase also
>make
Sorry for the OT, perhaps this is interesting for somebody:
I've just notice that Google splits Angular2 into a TypeScript and a pure
Dart version
including creating a dedicated AngularDart team:
http://news.dartlang.org/2016/07/angulardart-is-going-all-dart.html
http://angularjs.blogspot.de/2016
Thinking about this some more, I think an svg should have a different API.
SVG elements should inherit from UIBase and have the full capabilities
For one, I’m not sure primitives should implement beads. UIBase also makes a
lot of assumptions based on normal DOM elements. SVG has quite a few attri
I propose to have a single class. It could have a get
drawnElement():WrappedHTMLElement which the transform bead, or other
clients, would reference when interested in DOM manipulation. The condition
would be implemented once there.
Again, this is assuming wrapping in doesn't somehow make it a
can
How do you propose merging them?
Do you mean to have a single class that figures out what markup to use based on
what it’s added to? Or do you mean have two separate classes which are
determined in MXML?
There’s probably going to have to be a lot of conditional code to deal with a
single class
Unless Rect and RectComponent have different APIs I would elect to merge
them. We don't want to make the client think too much on what s/he should
use.
If we change IUIBase.addedToParent() to
IUIBase.addedToParent(parent:IUIBase) we can probably make the necessary
adjustments there. That also work
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.
For my port this is causing two issues:
1. It’s hard to find all the
I prefer to make things a little more explicit:
would be
would be
would be
would be
would do drawRect() on the containing canvas
would be and drawRect()
would be drawCircle() on the containing canvas
would be and drawCircle()
I’m not sold on the names. Maybe something like WrappedR
25 matches
Mail list logo
