-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow easily renaming multiple nodes #69087
Conversation
380ce0b
to
a03291e
Compare
Undo error fixed, but I had to do a little refactoring. Previously SceneTreeEditor's items held NodePath in their metadata. Now they use ObjectID. I added some helper methods to handle that easier. If something was accessing these nodes from outside |
020f1c3
to
cfb866c
Compare
Is it possible to rename an interleaved selection? Like: node2, node6, node8, node9 -> Test, Test2, Test3, Test4? |
cfb866c
to
be58d7f
Compare
be58d7f
to
7769406
Compare
So I took a look at it, the code seems great and straight forward, I don't have any problem with the implementation. But while doing the worst i could to make it break I did found a few bug and strange behaviour I'll try to order them from most important to sidenotes that are not really important and might only be a personnal point of view.
|
|
|
7769406
to
9063ab9
Compare
I resolved 3, 4 and 6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So reviewing your code made me see some short comings of #76376 I put some review but most likely this PR will be better after I fixed the shortcomings I found.
I tested different cases and it works correctly, but seems to break node paths in very specific cases .-. Maybe it's something that could be fixed later, idk.
Most likely this is this issue #76192. There is a PR but it has to be rebased on my last changes on this part.
Edit : you found it while I was reviewing ^__^
void SceneTreeEditor::rename_node(Node *p_node, const String &p_name, TreeItem *p_item) { | ||
TreeItem *item; | ||
if (p_item) { | ||
item = p_item; // During batch rename the paths may change, so using _find() is unreliable. | ||
} else { | ||
item = _find(tree->get_root(), p_node->get_path()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should just iterate through the node in reverse order so that every node still find it's item as this is what is done for batch rename currently. For this you can just replace push_back
by push push_front
at line 1029.
I know this is not great as nodes will be numbered from bottom to top and would need fixing but I think fixing this is another PR job. For now this PR should aim to keep consistency with what batch rename does.
editor/gui/scene_tree_editor.cpp
Outdated
void SceneTreeEditor::_renamed(TreeItem *p_item, TreeItem *p_batch_item, Node *p_node) { | ||
Node *n; | ||
if (p_node) { | ||
n = p_node; // During batch rename the paths may change, so using metadata is unreliable. | ||
} else { | ||
n = get_node(p_item->get_metadata(0)); | ||
} | ||
ERR_FAIL_NULL(n); | ||
|
||
String new_name; | ||
if (p_batch_item) { | ||
if (!p_batch_item->get_meta(SNAME("use_class"), false)) { | ||
new_name = p_batch_item->get_text(0); | ||
} | ||
} else { | ||
new_name = p_item->get_text(0); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
once the lower part is handled by rename_node
(#78292).I think the rest of this function can be integrated into the _edited
function this will make clearer and more readable code.
@ajreckof Would you be interested in doing the changes you requested? I rebased and tested the PR and it still works. If I understand correctly, it might have some inconsistencies with batch rename, but right now it's in mergable state and this can be improved in a follow-up. |
Yes it shouldn't take me long maybe an hour or so I think. Your rebased PR should work but will most likely recreate bugs that were fixed on batch rename and simple rename. |
Which bugs? |
That seems okay I would still include my suggestion of removing the _renamed function and calling directly the rename_node function with the right parameter as what is done in _renamed is already done in rename node |
Uh can you make a separate patch for that? >_> |
of course here is the updated patch https://github.com/KoBeWi/godot/compare/million_of_names...ajreckof:godot:millions-of-names?expand=1 Edit : This patch also fix a bug with your implementation that prevent renaming with multi-rename multiple nodes that are unique name as unique name is checked before adapting to the parent. |
I think this feature could coexist with the existing batch rename dialog #15928. However, from a UX perspective, it would be beneficial if, instead of just displaying one |
Indeed, it's not possible without some nasty hacks and workarounds. Not really an issue in my opinion, but it may hurt discoverability. For this to be more discoverable both Rename and Batch Rename should be available on the popup menu when selecting multiple nodes but that remains to be seen later. |
strange see how I proposed it here #69087 (comment) and it was said to be resolved here #69087 (comment) but effectively when I test it isn't appearing
see for better context : #69087 (comment) |
I fixed the missing Rename option for multiple nodes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally (rebased on top of master
f2045ba), it mostly works as expected.
Only entries that are located below the currently focused TreeItem (see the gray focus outline) are renamed, so if you select from bottom to top, only one entry will be renamed.
simplescreenrecorder-2024-03-02_20.46.46.mp4
Considering there's been talk to hide this gray focus outline in Tree, I suggest not changing the behavior based on where the focused item is and always rename all selected items.
Fixed. |
When the root is selected it will not rename it and start from the next one. |
Co-authored-by: ajreckof <tbonhoure@ymail.Com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, it works as expected now (including when nodes at different levels are selected, or when both parent and children are selected).
Thanks! |
I wanted this for a long time. The batch rename dialog is an overkill for such basic operation 😒
Putting as draft, because undo is broken.