Skip to content
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

Merged
merged 1 commit into from
Mar 4, 2024

Conversation

KoBeWi
Copy link
Member

@KoBeWi KoBeWi commented Nov 24, 2022

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.

@KoBeWi KoBeWi added this to the 4.x milestone Nov 24, 2022
@KoBeWi KoBeWi marked this pull request as ready for review November 24, 2022 12:59
@KoBeWi
Copy link
Member Author

KoBeWi commented Nov 24, 2022

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 scene_tree_editor.cpp, it would be now broken, so hopefully it wasn't used anywhere 🙃

@KoBeWi KoBeWi force-pushed the million_of_names branch 2 times, most recently from 020f1c3 to cfb866c Compare November 24, 2022 14:33
@AttackButton
Copy link
Contributor

Is it possible to rename an interleaved selection? Like:

node2, node6, node8, node9 -> Test, Test2, Test3, Test4?

@KoBeWi
Copy link
Member Author

KoBeWi commented Dec 23, 2022

godot windows editor dev x86_64_0dq1RCl2ak

@ajreckof
Copy link
Member

ajreckof commented Apr 14, 2023

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.

  1. When editing multiple node. StringPathNodePath will be badly updated which isn't a case when editing element one at a time. But this also happens with Batch edit so maybe it is okay to have a bug with this here too. (I'm not sure it has been reported yet for Batch Edit). it feels like the rename function is not designed to have multiple rename in the same frame
  2. You can edit outside the list by going to a node with the arrows. This is not a problem in general but will make strange behavior especially since there is not enough readability. For example, if you select a node you rename it you then go down with the arrow and rename this other node and unfortunately the previous node is also renamed at the same time. I think if the node is outside of the selection it should not rename selected nodes.

  3. When changing the name of one node to an empty string it will rename the node to the name of its class but this behavior was not reimplemented in multi edit so it will just rename everyone from the name of the class being edited instead of their own class.
  4. Edit disappear from popup when multiple node are selected since we are adding a particular behavior on this it might be a good idea to make it reappear maybe with a slightly modified name. Simple Batch Edit? Multi-edit ?
  5. After multi editing the inspector will edit the first node instead of the batch of node
  6. When modifying the name to the name of the focused node it won't rename any of the node as the name of the focused node didn't change. It might be problematic if someone is editing the property of a batch of node and then want to rename the nodes and just paste a value and nothing happens. Right now you have to either unselect the node modify and then reselect your node to continue with your edition of those nodes or set the value to something arbitrary and then setting to the value you want.

  7. Right now it feels like we are only editing the focused node. I’m not sure how to improve it :(

@KoBeWi
Copy link
Member Author

KoBeWi commented Apr 14, 2023

  1. What is StringPath 🤔
  2. See this issue: Arrow keys doesn't select objects on the scene hierarchy  #12544 If you move within nodes of the same type, the nodes are correctly deselected
  3. Makes sense
  4. Makes sense
  5. The inspector is consistent with what is selected after rename, so it's not really a problem
  6. I'll see if it can be fixed easily
  7. The PR was inspired by Windows' file explorer, which also behaves like this
    image

@ajreckof
Copy link
Member

ajreckof commented Apr 14, 2023

  1. sorry for first one it is NodePath. I will make a different bug issue. I think the solution does not need to be in this PR as the problem is also present in Batch Edit and most likely the solution should be in both. I'll look if the issue already exists. If it does not I will create it. If it does I will update this with a link to it. (Edit : I couldn't find one so i created one here Batch Rename try to update NodePath but fails which results in invalid NodePath error #76070)
  2. okay so it was just another bug
  3. N/A
  4. N/A
  5. N/A
  6. N/A
  7. That's why i placed it last as i didn't have any idea how to make it better and didn't have any other example of similar behaviour, if you feel it is easily understandable by most people than i think it's okay

@KoBeWi KoBeWi requested a review from a team as a code owner April 14, 2023 17:41
@KoBeWi
Copy link
Member Author

KoBeWi commented Apr 14, 2023

I resolved 3, 4 and 6

@KoBeWi
Copy link
Member Author

KoBeWi commented Jun 15, 2023

Rebased after #76376
I reworked the code using the new methods and it's now simpler.

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.
EDIT: Seems like it's what #76575 fixes.

Copy link
Member

@ajreckof ajreckof left a 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 ^__^

Comment on lines +965 to +1039
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());
}
Copy link
Member

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 Show resolved Hide resolved
Comment on lines 1048 to 1146
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);
}
Copy link
Member

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.

@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 1, 2024

@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.

@ajreckof
Copy link
Member

ajreckof commented Mar 1, 2024

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.

@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 1, 2024

Which bugs?

editor/gui/scene_tree_editor.cpp Show resolved Hide resolved
editor/gui/scene_tree_editor.cpp Outdated Show resolved Hide resolved
@ajreckof
Copy link
Member

ajreckof commented Mar 2, 2024

I'd rather make the naming correct and your changes + related fixes can be done in a follow up.

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

@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 2, 2024

Uh can you make a separate patch for that? >_>

@ajreckof
Copy link
Member

ajreckof commented Mar 2, 2024

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.

@AThousandShips AThousandShips changed the title Allow to easily rename multiple nodes Allow easily renaming multiple nodes Mar 2, 2024
@nongvantinh
Copy link
Contributor

nongvantinh commented Mar 2, 2024

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 LineEdit for the first selected node, we could display LineEdits for all selected nodes and update changes as we type. However, the limitation of the current system only allows editing one node at a time. Therefore, I believe it is impossible to achieve.

@Mickeon
Copy link
Contributor

Mickeon commented Mar 2, 2024

we could display LineEdits for all selected nodes and update changes as we type

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.

@ajreckof
Copy link
Member

ajreckof commented Mar 2, 2024

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

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 LineEdit for the first selected node, we could display LineEdits for all selected nodes and update changes as we type. However, the limitation of the current system only allows editing one node at a time. Therefore, I believe it is impossible to achieve.

see for better context : #69087 (comment)

@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 2, 2024

I fixed the missing Rename option for multiple nodes.

Copy link
Member

@Calinou Calinou left a 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.

@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 2, 2024

Fixed.

@ajreckof
Copy link
Member

ajreckof commented Mar 3, 2024

When the root is selected it will not rename it and start from the next one.

Co-authored-by: ajreckof <tbonhoure@ymail.Com>
@KoBeWi
Copy link
Member Author

KoBeWi commented Mar 3, 2024

#69087 (comment)

@akien-mga akien-mga modified the milestones: 4.x, 4.3 Mar 4, 2024
Copy link
Member

@Calinou Calinou left a 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).

@akien-mga akien-mga merged commit 9f4a764 into godotengine:master Mar 4, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

@KoBeWi KoBeWi deleted the million_of_names branch March 4, 2024 19:46
@raulsntos raulsntos mentioned this pull request Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants