You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently working on a general purpose data editor for C# objects (can be found on github here), for this project I require a tree that users can drag & drop items to reorder items in arrays.
Describe the problem or limitation you are having in your project
This problem already had two bugs filed for it, here and here. The main problem is that dropping items in a tree is unreliable when a treeitem has children. Despite there being two issues filed for this problem there could be multiple ways to solve this problem which is why I am filing this proposal to hopefully start a discussion and find a prefered solution.
As you can see the line renders correctly below the item that has no children (left side), however for the item with children it never renders below the item (right side). This can also be reproduced in the godot node tree,
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Currently each tree item has three drag & drop zones, I have tried to illustrate this in the image below.
Red - Top
Green - Middle
Blue - Bottom
Where you drop an item can be resolved by using the method get_drop_section_at_position. You can of course adjust how your own tree implementation behaves, but the visual drag & drop indicator that appears in the tree you have no control over.
My proposal is that we keep these drop zones as is but we adjust how the visual indicators work for nodes with children. I think the most logical way is that the three drop zones work as follows when an item has children:
Top - Drops the item above the current item as it already does (indicator above node)
Middle - Drop the item as the first child of the current item (indicator indented to child level, above first child)
Bottom - Drops the item below the current item on the same level (indicator on same indentation as the node, but below the last child).
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
In the image above consider that we are dropping an item on top of the node "Control4", I have indicated where I would expect the indicators to be depending on if you are dropping in the Top (Red), Middle (Green) or Bottom (Blue) zone of the node.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Unfortunately there is no real workaround for the visual indicator of the tree. In addition the scene tree in the editor (and any other tree like FileSystem tree) also has the same problems which you can't easily work around. Most people who worked with godot for a while has encountered the problem of dragging a node below a node with children when the node with children is the last node in the tree. It is impossible and you have to drag the node with children up above your node.
Is there a reason why this should be core and not an add-on in the asset library?
Since this issue also exists inside the godot editor scene tree (and other editor trees) this should be fixed in core.
The text was updated successfully, but these errors were encountered:
Calinou
changed the title
Improve drag and drop for Tree (inlcuding scene tree in editor)
Improve drag and drop for Tree (including scene tree in editor)
Aug 25, 2021
Describe the project you are working on
I am currently working on a general purpose data editor for C# objects (can be found on github here), for this project I require a tree that users can drag & drop items to reorder items in arrays.
Describe the problem or limitation you are having in your project
This problem already had two bugs filed for it, here and here. The main problem is that dropping items in a tree is unreliable when a treeitem has children. Despite there being two issues filed for this problem there could be multiple ways to solve this problem which is why I am filing this proposal to hopefully start a discussion and find a prefered solution.
As you can see the line renders correctly below the item that has no children (left side), however for the item with children it never renders below the item (right side). This can also be reproduced in the godot node tree,
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Currently each tree item has three drag & drop zones, I have tried to illustrate this in the image below.
Where you drop an item can be resolved by using the method get_drop_section_at_position. You can of course adjust how your own tree implementation behaves, but the visual drag & drop indicator that appears in the tree you have no control over.
My proposal is that we keep these drop zones as is but we adjust how the visual indicators work for nodes with children. I think the most logical way is that the three drop zones work as follows when an item has children:
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
In the image above consider that we are dropping an item on top of the node "Control4", I have indicated where I would expect the indicators to be depending on if you are dropping in the Top (Red), Middle (Green) or Bottom (Blue) zone of the node.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Unfortunately there is no real workaround for the visual indicator of the tree. In addition the scene tree in the editor (and any other tree like FileSystem tree) also has the same problems which you can't easily work around. Most people who worked with godot for a while has encountered the problem of dragging a node below a node with children when the node with children is the last node in the tree. It is impossible and you have to drag the node with children up above your node.
Is there a reason why this should be core and not an add-on in the asset library?
Since this issue also exists inside the godot editor scene tree (and other editor trees) this should be fixed in core.
The text was updated successfully, but these errors were encountered: