Add a check that makes it not work for dragging into anything except a standard markdown view edit mode (for now)

[GitMurf]

Thanks @zsviczian … I have been having a lot of issues like this with a lot of different plugins that have their own views types.

To get it released I am probably going to add a check that makes it not work for dragging into anything except a standard markdown view edit mode.

But excalidraw is the first plugin I plan to “optimize” for in an early update after initial release to the community plugin store.

so many darn corner cases to handle with drag and drop!!

Originally posted by @GitMurf in #30 (comment)

[zsviczian]

NP. If I were building the drag and drop plugin, I would probably add a setting to "create block reference on drag start", then would place the payload into draggable, and leave the rest to the receiver plugin and the user.

…

On Wed, Oct 27, 2021, 17:58 GitMurf ***@***.***> wrote: Thanks @zsviczian <https://github.com/zsviczian> … I have been having a lot of issues like this with a lot of different plugins that have their own views types. To get it released I am probably going to add a check that makes it not work for dragging into anything except a standard markdown view edit mode. But excalidraw is the first plugin I plan to “optimize” for in an early update after initial release to the community plugin store. so many darn corner cases to handle with drag and drop!! *Originally posted by @GitMurf <https://github.com/GitMurf> in #30 (comment) <#30 (comment)>* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNRO6XFOL5AI76EVBTEHYLUJAORZANCNFSM5G2WZZSQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[GitMurf]

@zsviczian so if I am understanding you correctly, basically a way where when I detect a non standard pane/view being dragged over and dropped into, instead of completely stopping it from working (like I proposed in this Issue), simply allow it to add the block reference to the drag event and then allow the native drag and drop Obsidian core to process the drop (as if my plugin didn’t exist). Then this would allow another plugin (like Excalidraw) to also decide how to handle the Drop event if they want to do something else with the dropped text.

So in summary, if my plugin detects being dropped into a non standard markdown edit view/pane then update the text accordingly in the Drag Event data (e.g. block reference or copied dragged block text) but then do not process the Drop event with my plugin and instead allow it to be handled by obsidian Native and/or another plugin that decides to tap into the Drop event. Does that make sense? Is this what you were suggesting?

[zsviczian]

exactly. BTW Excalidraw already for a few months detects if a drop is a block reference from drag and drop blocks and handles the drop.

…

On 2021. Oct 27., Wed at 21:17, GitMurf ***@***.***> wrote: @zsviczian <https://github.com/zsviczian> so if I am understanding you correctly, basically a way where when I detect a non standard pane/view being dragged over and dropped into, instead of completely stopping it from working (like I proposed in this Issue), simply allow it to add the block reference to the drag event and then allow the native drag and drop Obsidian core to process the drop (as if my plugin didn’t exist). Then this would allow another plugin (like Excalidraw) to also decide how to handle the Drop event if they want to do something else with the dropped text. So in summary, if my plugin detects being dropped into a non standard markdown edit view/pane then update the text accordingly in the Drag Event data (e.g. block reference or copied dragged block text) but then do not process the Drop event with my plugin and instead allow it to be handled by obsidian Native and/or another plugin that decides to tap into the Drop event. Does that make sense? Is this what you were suggesting? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNRO6VOWHUPH5RZDB32B7LUJBF5NANCNFSM5G2WZZSQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[GitMurf]

Cool. I will implement this and let you know when ready to test.