godotengine
Place imported files in the hovered EditorFileDock folder
Fixes #80667
Files that are dragged into Godot from the File Explorer will now attempt to place themselves into the hovered location of the EditorFileDock. Both the Tree view and the split view are supported. If a file is hovered, it will use the base dir, meaning it's placed as a sibling.
If no file is hovered, the file will revert to the original logic, which is to place the file into the last selected tree item, or the root, if none is selected.
WARNING: This PR lacks any hovered animation or UX support. This is because when a file is being dragged into Godot, Godot lacks focus. Additionally, the support for highlights/hover effect in the Tree node requires the can_drop_data callback to return true, which isn't the case because OS file drag isn't using the standard file drag/drop system that Control nodes do.
As part of this PR, I created and exposed methods on ItemList and Tree, for getting items under the mouse cursor. I believe these to be useful methods as I've often written them myself for my own editor plugins. The position is calculated relative to the parent node, which I believe will always be correct.
Hi @SirLich,
We talked about this PR on Rocket.Chat, and as I said, it's a feature I attempted implementing myself but dropped because I couldn't find a simple way to have Godot grab focus while dragging a file from the file explorer. Really interested in seeing where this goes, so I'm following this PR closely and I'll try my best to help figuring out how to best achieve that.
@AlexOtsuka I think the most helpful thing for you to do would be to try out the branch, and let me know any feedback. I fully admit that the current PR is very weak on the UX. The question I need answered is whether this halfway solution is better than nothing, or whether we had better wait for a more proper solution.
You used a merge commit to update your branch, please use rebase in the future instead, see here
Or in this case you might have forgotten to git pull your branch before updating
Squashed everything out. That sadly erases the contributions from yourself @AThousandShips. I've kept the line "Co authored by .." in the message. Hopefully that's enough?
Sorry!
That's no worries! We usually don't add co-authorship for reviews, unless they're significant collaboration or new stuff, so that's as we usually do :)
You need to add 2 blank lines between commit message and co-author note to make it count.
Message
Co-authored by
EDIT: Although if this was added automatically when you accepted suggestions, you don't need to keep it. Usually co-author notes are added when another user contributes a relatively significant part of code to the PR.
OK sorry for the amateur hour PR. Something got all messed up and I was missing includes among a bunch of other issues.
I re-tested the latest version and it works locally, and files are re-saved with clang tidy.
@AlexOtsuka I think the most helpful thing for you to do would be to try out the branch, and let me know any feedback. I fully admit that the current PR is very weak on the UX. The question I need answered is whether this halfway solution is better than nothing, or whether we had better wait for a more proper solution.
Alright, I built and tested this.
As a proof of concept, it does a good job at presenting your goals. The feature seems to work as expected, but requires proper testing to make sure it doesn't break on edge cases. Implementing this for split view isn't too complicated either, and should be made easier by the PR I'm currently working on (https://github.com/godotengine/godot/pull/90062).
As for whether this is better than nothing, my personal opinion is that as long as it's not breaking anything, it's probably a yes? I think that generally the way it works here makes more sense than automatically picking the previously selected folder no matter where the files are dropped.
Of course, being able to grab focus on drag and display proper highlighting by propagating a notification down to FileSystemDock::_tree_gui_input() and FileSystemDock::_file_list_gui_input() would be the dream scenario and my initial vision for the feature.
Great work so far!
Split view should be working, I think? I check for hovered items in both the tree control and the files control. I guess the edge case would be dropping into the split view itself, not ON any particular item -in that case the fallback behavior would place the file into the last hovered folder.
I have a ton of failing CI checks though, so it will need more time in the oven. I will probably start investigating the focus issue again as well, as I agree it could be really much better :)
Split view should be working, I think? I check for hovered items in both the tree control and the files control. I guess the edge case would be dropping into the split view itself, not ON any particular item -in that case the fallback behavior would place the file into the last hovered folder.
Didn't work for me when dropping on a file or folder in split view, but I fixed it by replacing
to_path = item_list_control->get_item_text(item_index).get_base_dir();
with
to_path = item_list_control->get_item_metadata(item_index);
to_path = to_path.get_base_dir();
(pretty sure get_item_text() just returns the String displayed on the item, not the file path).