Renaming an ID through RNA does not consistently increment OTHER or CURRENT ID in case of name collision #71244

New Issue

Yannick Castaing · 2019-10-31T15:07:39+01:00

Yannick Castaing commented

2019-10-31 15:07:39 +01:00

Renaming an ID through RNA does not consistently increment either the current ID or the other ID in case of name collision. This depends on the existing order of the data-blocks before the rename happens.

As pointed out in the comment below by @ideasman42, fixing this in one way or the other is trivial. But we have to choose one of the two solutions:

Add incremented number suffix to renamed ID (this seems to be the soundest solution, as it will ensure we never silently rename a random other ID).
Add incremented number suffix to the other ID.

Note that it should also be ensured that behavior is consistent with Outliner renaming code as well.

Original Report

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.60

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449
Worked: (optional)

Short description of error
when we try to rename an object with an already used name,, it will rename the existing occurence, not the incoming one

Exact steps for others to reproduce the error
works with the default scene (with Cube, Light, Camera) :

take the Cube, x2 clic on the name, rename it in "Camera". Enter
the original Camera (previously named "Camera") will be renamed in "Camera.001" and the Cube will be renamed in "Camera"

I gess it should be the opposite : the incoming similar name is incremented, but the original name stays the same

Renaming an ID through RNA does not consistently increment either the current ID or the other ID in case of name collision. This depends on the existing order of the data-blocks before the rename happens. As pointed out in the comment below by @ideasman42, fixing this in one way or the other is trivial. But we have to choose one of the two solutions: * Add incremented number suffix to renamed ID (this seems to be the soundest solution, as it will ensure we never silently rename a random other ID). * Add incremented number suffix to the other ID. Note that it should also be ensured that behavior is consistent with Outliner renaming code as well. ------------ Original Report ----------------- **System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.60 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449` Worked: (optional) **Short description of error** when we try to rename an object with an already used name,, it will rename the existing occurence, not the incoming one **Exact steps for others to reproduce the error** works with the default scene (with Cube, Light, Camera) : - take the Cube, x2 clic on the name, rename it in "Camera". Enter - the original Camera (previously named "Camera") will be renamed in "Camera.001" and the Cube will be renamed in "Camera" I gess it should be the opposite : the incoming similar name is incremented, but the original name stays the same

Yannick Castaing commented

2019-10-31 15:07:39 +01:00

Added subscriber: @BoUBoU

blender-admin commented

2019-10-31 15:07:39 +01:00

#90052 was marked as duplicate of this issue

Campbell Barton commented

2019-10-31 17:39:26 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-10-31 17:39:26 +01:00

This has come up before.

Internal detail: which data-block gets numbered depends on the current order, So if you first rename the cube to A, then rename to Camera, this wont happen.

We can change this so the item you're renaming always gets numbered and you never accidentally rename other items.

diff --git a/source/blender/makesrna/intern/rna_ID.c b/source/blender/makesrna/intern/rna_ID.c
index 49fdf9c67d5..6bc79c3baa9 100644
--- a/source/blender/makesrna/intern/rna_ID.c
+++ b/source/blender/makesrna/intern/rna_ID.c
@@ -145,7 +145,7 @@ void rna_ID_name_set(PointerRNA *ptr, const char *value)
   ID *id = (ID *)ptr->data;
   BLI_strncpy_utf8(id->name + 2, value, sizeof(id->name) - 2);
   BLI_assert(BKE_id_is_in_global_main(id));
-  BLI_libblock_ensure_unique_name(G_MAIN, id->name);
+  BKE_libblock_rename(G_MAIN, id, value);
 
   if (GS(id->name) == ID_OB) {
     Object *ob = (Object *)id;

However sometimes users want this behavior, having to find the item and rename it so this one can take it's place (while arguably correct) is tedious.

This is more a design task though, how it works isn't great but isn't a mistake in the code.

This has come up before. **Internal detail:** which data-block gets numbered depends on the current order, So if you first rename the cube to `A`, then rename to `Camera`, this wont happen. We can change this so the item you're renaming always gets numbered and you never accidentally rename other items. ``` diff --git a/source/blender/makesrna/intern/rna_ID.c b/source/blender/makesrna/intern/rna_ID.c index 49fdf9c67d5..6bc79c3baa9 100644 --- a/source/blender/makesrna/intern/rna_ID.c +++ b/source/blender/makesrna/intern/rna_ID.c @@ -145,7 +145,7 @@ void rna_ID_name_set(PointerRNA *ptr, const char *value) ID *id = (ID *)ptr->data; BLI_strncpy_utf8(id->name + 2, value, sizeof(id->name) - 2); BLI_assert(BKE_id_is_in_global_main(id)); - BLI_libblock_ensure_unique_name(G_MAIN, id->name); + BKE_libblock_rename(G_MAIN, id, value); if (GS(id->name) == ID_OB) { Object *ob = (Object *)id; ``` However sometimes users want this behavior, having to find the item and rename it so this one can take it's place (while arguably *correct*) is tedious. This is more a design task though, how it works isn't great but isn't a mistake in the code.

Bastien Montagne changed title from ~~Automatic renaming increment the existing name, and not the incoming one~~ to Renaming an ID through RNA does not consistantly increment OTHER or CURRENT ID in case of name collision

2019-12-18 16:36:30 +01:00

Bastien Montagne commented

2019-12-18 16:36:30 +01:00

Added subscriber: @mont29

Bastien Montagne changed title from ~~Renaming an ID through RNA does not consistantly increment OTHER or CURRENT ID in case of name collision~~ to Renaming an ID through RNA does not consistently increment OTHER or CURRENT ID in case of name collision

2019-12-18 16:41:12 +01:00

Bastien Montagne commented

2019-12-18 16:43:21 +01:00

I would also rather just increment current ID's name, instead of changing some random other ID's name…

We could also add an operator to allow the other behavior (i.e. always set affected ID to exactly given name, and rename the other in case of name collision)?

I would also rather just increment current ID's name, instead of changing some random other ID's name… We could also add an operator to allow the other behavior (i.e. always set affected ID to exactly given name, and rename the other in case of name collision)?

Campbell Barton commented

2019-12-19 04:45:22 +01:00

@mont29 while incrementing the current ID is the correct solution - I suspect some users will run into situations where they don't know or care what the other ID is called and want to take it's name.
Did you have an idea how this operator would be accessed?

I was thinking we could...

Always increment the current ID (as you suggest).
Have an exception for the UI, which detects the case where the name started out with a number and the only edit was to remove this number. In this case rename the other data-block.

This way only intentional removal of the extension renames the other data & only from the UI.

The Python API could have a function for this if it's needed.

@mont29 while incrementing the current ID is the correct solution - I suspect some users will run into situations where they don't know or care what the other ID is called and want to take it's name. Did you have an idea how this operator would be accessed? I was thinking we could... - Always increment the current ID *(as you suggest)*. - Have an exception for the UI, which detects the case where the name started out with a number and the only edit was to remove this number. In this case rename the other data-block. This way only intentional removal of the extension renames the other data & only from the UI. The Python API could have a function for this if it's needed.

Bastien Montagne commented

2019-12-20 16:19:47 +01:00

Added subscribers: @WilliamReynish, @pablovazquez

Bastien Montagne commented

2019-12-20 16:19:47 +01:00

@ideasman42 I don’t have a very strong opinion, but even for UI, I would not try to be smart… even though I can see how much more friendly/handy that behavior would be, compared to having to call some 'force rename' operator, this would introduce a weird special behavior which might backfire in some cases as well.

Note that we want to add a 'contextual' menu to ID template, since we are adding more and more operations there and we cannot keep adding buttons and/or weird 'Shift-click' thingies. So exposing that would be a natural place for that 'force rename' operator I guess? We could also add some 'Shift-click' on the name field to trigger 'force rename' behavior I guess…

Think we could use the #user_interface team advice here as well, @pablovazquez ? @WilliamReynish ?

@ideasman42 I don’t have a very strong opinion, but even for UI, I would not try to be smart… even though I can see how much more friendly/handy that behavior would be, compared to having to call some 'force rename' operator, this would introduce a weird special behavior which might backfire in some cases as well. Note that we want to add a 'contextual' menu to ID template, since we are adding more and more operations there and we cannot keep adding buttons and/or weird 'Shift-click' thingies. So exposing that would be a natural place for that 'force rename' operator I guess? We could also add some 'Shift-click' on the name field to trigger 'force rename' behavior I guess… Think we could use the #user_interface team advice here as well, @pablovazquez ? @WilliamReynish ?

Laurent Noel commented

2020-03-16 11:05:19 +01:00

Added subscriber: @c2ba

Benjamin Sauder commented

2020-05-11 10:50:34 +02:00

Added subscriber: @kioku

Benjamin Sauder commented

2020-05-11 10:50:34 +02:00

As I have run into this recently - this behaviour should change. Hidden renaming of things is really bad - especially if you setup names carefully for further processing.

Guess a 'force' flag in the F2 rename would be fine tho.

As I have run into this recently - this behaviour should change. Hidden renaming of things is really bad - especially if you setup names carefully for further processing. Guess a 'force' flag in the F2 rename would be fine tho.

Bastien Montagne commented

2021-07-23 10:36:42 +02:00

Added subscribers: @marty3000, @PratikPB2123, @lichtwerk, @kursadk

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Renaming an ID through RNA does not consistently increment OTHER or CURRENT ID in case of name collision #71244

Original Report