Conversation
| /** Invokes an "exported" native method on the View instance */ | ||
| juce::var invokeMethod(const juce::String &method, const juce::var::NativeFunctionArgs &args); | ||
|
|
||
| void checkMouseEnter(const juce::MouseEvent& e); |
There was a problem hiding this comment.
This should really be called something like checkMouseEnterAndExit.
| void View::mouseExit (const juce::MouseEvent& e) | ||
| { | ||
| dispatchViewEvent("onMouseLeave", detail::makeViewEventObject(e, *this)); | ||
| if (!reallyContains(e.getPosition(), true)) |
There was a problem hiding this comment.
reallyContains returns true even if the mouse is over one of this components children.
|
|
||
| juce::Component* componentUnderMouse; | ||
|
|
||
| void mouseDrag(const juce::MouseEvent &e) override { |
There was a problem hiding this comment.
Used to translate mouseDrags into enter and exit events
There was a problem hiding this comment.
Hmm interesting, won't ReactAppRoot not get this callback if the mouse is dragged over a child component? https://docs.juce.com/master/classComponent.html#aff01e4d339bda474a66984b709044b63
Or is AppRoot getting this callback at all times?
There was a problem hiding this comment.
see View::mouseDrag I forward child drag events onto ReactAppRoot::mouseDrag.
but yes, its pretty ugly. Another way to handle it would be making ReactAppRoot a mouse listener for all its children I suppose.
There was a problem hiding this comment.
Got it, thanks! Finally coming back around to this, sorry for the delay.
So, reading this through again with a better understanding, I actually think this is quite like the way juce implements its own drag and drop patterns, except here we're sort of re-implementing it with ReactAppRoot == DragAndDropContainer and View == DragAndDropTarget. (See https://github.com/juce-framework/JUCE/blob/b8206e3604ebaca64779bf19f1613c373b9adf4f/modules/juce_gui_basics/mouse/juce_DragAndDropContainer.cpp)
This has me thinking then, especially in the context of the approach we laid out in the drag and drop issue (see #60 (comment)), that perhaps we should just merge this goal into that work. The approach laid out in that issue is basically 1 step away from solving this problem here, and we can nudge the dragstart/dragmove/dragend callbacks that each View will receive (because its a DragAndDropTarget) to correctly send mouseenter/mouseleave callbacks as well.
What do you think?
2 participants
Draft for #230
Things this does:
Things this doesn't do:
BIG DISCLAIMER: I'm not a C++ guy. I'm sure the final PR will have much better code. Theres probably bugs. This is just to facilitate a design discussion.