search

ptmt / react-native-macos

[deprecated in favor of https://microsoft.github.io/react-native-windows/] React Native for macOS is an experimental fork for writing desktop apps using Cocoa
MIT License
11.25k stars 429 forks source link

Fix for bug where mouse coordinates are wrong #239

Open russellmcc opened 5 years ago

russellmcc commented 5 years ago

This occurs when our main react view is not the contentView of a window. Touch coordinates are in window coordinates, but hitTest expects coordinates in the coordinate system of our superview.

This is my first PR, let me know what I can do to get this in.

aleclarson commented 5 years ago

When does self.view not have a superview?

Also, please try out #228, which is the future of "touch" handling in react-native-macos.

russellmcc commented 5 years ago

According to apple's docs, NSViews have a nil superview when they are not in a view hierarchy. I think the most common case for this is when it's the contentView of the window. I'm not familiar enough with react to know if react views can never be the contentView - if this is the case, I'm happy to remove the check.

Thanks for the tip on #228! I'll try out the branch soon and let you know how it goes.

russellmcc commented 5 years ago

I just checked, #228 first of all still has this problem, and additionally has another problem for clients that don't use RCTWindow - it seems that line 90 on RCTContentView.m on that branch flips the coordinate system - but this is inappropriate when not using RCTWindow. After removing this line, that branch showed the same problems as master. I can see what happens if I use RCTWindow instead, but in my use case I'm a view in a window someone else created, so this approach won't work for me.

russellmcc commented 5 years ago

Sorry, I don't have the ability to move to RCTWindow as it stands now since my NSWindow is created long before my RCTBridge!

russellmcc commented 5 years ago

I've just added another, related commit to this branch; I hope that's okay. More than happy to split these out into separate PRs if that's more convenient for you.

An explanation: I am trying to use lottie views as interactive controls. The current logic of checking if something is an RCTView doesn't work for this, because the actual type is LOTAnimationView. I've replaced this logic with the logic used in the ios version here, I think this makes more sense and is less surprising. Using this method I think is much more robust.

russellmcc commented 5 years ago

Anyone had time to give this another look? I'm still motivated to land this; and am willing to help however I can!