Only allow drag-and-drop to succeed on panes in the center workspace #19251
Conversation
|
Hey! 👋 We have recently started using This is good news: now the Atom code is more consistent and it's much easier to re-format the code to This change caused conflicts on your PR that we have automatically solved, hope you don't mind 😄 With ❤️, the Atom team. |
|
@50Wliu Good work on the PR. The PR is still in draft mode. What could be holding it back from being ready for review? |
|
I don't remember 😅. Regardless, I'll resolve the conflicts, and see if anything sparks my memory while doing so. |
Okay, my guess is just I wasn't satisfied with the drop effects not lining up as expected. This is still probably worth merging if the unit tests pass though and you can verify that dropping files on non-center panes don't create files. |
|
@50Wliu, the tests aren't passing : ( Do you think you have the time to work on this?
|
|
Looking at my old CoffeeScript tests, I somehow completely butchered moving them to JavaScript. Let me fix that now... |
|
It's 💚💚💚! |
|
Awesome stuff! Thanks for the contribution @50Wliu 🙇🏾 |
Requirements for Adding, Changing, or Removing a Feature
Issue or RFC Endorsed by Atom's Maintainers
Admittedly, this has not been endorsed by any maintainers (other than the fact that I'm submitting a PR for it now as a maintainer?).
Description of the Change
Previously, we would accept any drop request as valid in a drag-and-drop operation, regardless if we would actually do anything with it. Before signaling that a drop would be valid, we now check that 1) files are included in the drag store, and 2) the pane is in the workspace center.
The first check is entirely visual - this is to prevent the drop effect from changing to "move" instead of staying as "none" if the potential drop operation would be invalid.
The second check has an additional functional change - attempting to drop files onto docks no longer does anything. This is to prevent confusion, as TextEditors can only be opened in the center of the workspace, and I thought it was best to be explicit about that, even when initiating a drop operation. (Previously, dropping onto a dock would open the TextEditor in the workspace center, not the dock itself.)
Note: with this change, my drop effect on Windows is "copy" instead of "none" when the event is not prevented, and I can't figure out why. Maybe it's just a bug with Windows?
Edit: Maybe I need to look at 71a2797?
Alternate Designs
None.
Possible Drawbacks
You now must drop a file in the center workspace for a new TextEditor to be created.
Verification Process
Release Notes
N/A