WIP: Allow name-swapping when renaming IDs from the UI #119139

New Issue

Yegor · 2024-03-07T00:45:33+01:00

Yegor commented

2024-03-07 00:45:33 +01:00

When renaming a data-block, in case of name collision with another existing data-block of the same type, Blender will always add the 'numeric suffix' to the renamed ID (since 195bb4f8f5, see also #71244).

However, when renaming form the UI, it is sometimes better from user perspective to rename the existing name-colliding ID, instead, and keep specified name for the edited one (aka 'name swapping').

Implementing this behavior is technically trivial, but it has some UI & UX challenges. Some ideas:

Always do name swapping when renaming from the UI (ID widgets, Outliner, etc.).
Enable name-swapping though a dedicated operator.
- How to expose that in an easy way in UI?
...

Original report:

System Information
Operating system: Linux-5.15.0-97-generic-x86_64-with-glibc2.35 64 Bits, X11 UI
Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 525.147.05

Blender Version
Broken: version: 4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-15 17:25, hash: 401a2397db20
Worked: 4.0

Short description of error
You have two objects. Suzanne and Suzanne.001. If rename Suzanne.001 to Suzanne they would swap the names. So Suzanne becomes Suzanne.001 and vice versa. That was really handy throughout the history of Blender before 4.1.
So, is it a bug or a feature now?

PS: when you use Batch Rename operation and try to do the same, it does nothing too, but shows in the info that 1 object has been renamed. Maybe a separate bug, idk.

Exact steps for others to reproduce the error
Create two objects and try to name on of them with the name of the second one.

When renaming a data-block, in case of name collision with another existing data-block of the same type, Blender will always add the 'numeric suffix' to the renamed ID (since 195bb4f8f5, see also #71244). However, when renaming form the UI, it is sometimes better from user perspective to rename the existing name-colliding ID, instead, and keep specified name for the edited one (aka 'name swapping'). Implementing this behavior is technically trivial, but it has some UI & UX challenges. Some ideas: * Always do name swapping when renaming from the UI (ID widgets, Outliner, etc.). * Enable name-swapping though a dedicated operator. * How to expose that in an easy way in UI? * ... --------------------------------- _Original report:_ **System Information** Operating system: Linux-5.15.0-97-generic-x86_64-with-glibc2.35 64 Bits, X11 UI Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 525.147.05 **Blender Version** Broken: version: 4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-15 17:25, hash: `401a2397db20` Worked: 4.0 **Short description of error** You have two objects. Suzanne and Suzanne.001. If rename Suzanne.001 to Suzanne they would swap the names. So Suzanne becomes Suzanne.001 and vice versa. That was really handy throughout the history of Blender before 4.1. So, is it a bug or a feature now? PS: when you use Batch Rename operation and try to do the same, it does nothing too, but shows in the info that 1 object has been renamed. Maybe a separate bug, idk. **Exact steps for others to reproduce the error** Create two objects and try to name on of them with the name of the second one.

Yegor added the

labels 2024-03-07 00:45:34 +01:00

Pratik Borhade commented

2024-03-07 04:02:24 +01:00

Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f5

If rename Suzanne.001 to Suzanne they would swap the names

Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names.

Not a bug, closing.

Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f50df822ff820806edd5a87b5bc9d9da > If rename Suzanne.001 to Suzanne they would swap the names Also, this was bit consistent. In following file if you rename `Suzanne.001` object to `Suzanne.002` then it do not swap names. Not a bug, closing.

119139.blend

962 KiB

👎 3

Pratik Borhade closed this issue

2024-03-07 04:02:28 +01:00

Blender Bot added

and removed

labels 2024-03-07 04:04:00 +01:00

Yegor commented

2024-03-07 04:08:44 +01:00

I mean auto swapping names was good and handy...

👍 2

Paul Kotelevets commented

2024-03-07 05:11:08 +01:00

Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f5

Sounds like fixing broken nail with finger amputation. We need that functionality to handle massive datasets.

> Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f5 Sounds like fixing broken nail with finger amputation. We need that functionality to handle massive datasets.

👍 6

Pratik Borhade commented

2024-03-07 05:21:37 +01:00

Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names.

@1D_Inc ^

> Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names. @1D_Inc ^

Paul Kotelevets commented

2024-03-07 05:45:28 +01:00

@PratikPB2123 because the logics is different.
There is a difference between indexed (with numeric suffix - such as NAME.001, NAME.002, NAME.003 etc) and not indexed names (without numeric suffix - such as NAME)
Non-indexed name is the main, and all the indexed name copies are applicants which pretends to be the main in the form of a queue/stack.
This is why:

renaming Suzanne.001 object to Suzanne.002 then it do not swap names - because the lowest number is already occupied by itself.
backward renaming Suzanne.002 object to Suzanne.001 does swap names - because this way it pretends to be closer to the main in the queue of applicants.

If a scene contains only two objects Suzanne.003 and Suzanne.005, renaming Suzanne.003 into Suzanne.005 returns Suzanne.001 - because it is the lowest available index number in the queue/stack of Suzanne applicants.
So:

Renaming Suzanne.003 into Suzanne.005 will return Suzanne.001 - the lowest availbale index in the stack.
Renaming Suzanne.005 into Suzanne.003 will shift the touched elements in the stack.
Duplicating Suzanne.005 object will return Suzanne.001 (not Suzanne.006) - the lowest availbale index in the stack.

In this system the ability to rename an indexed applicant into the non-indexed main is essential for clones resolving via proper stack datahandling.

@PratikPB2123 because the logics is different. There is a difference between indexed (with numeric suffix - such as NAME.001, NAME.002, NAME.003 etc) and not indexed names (without numeric suffix - such as NAME) Non-indexed name is the main, and all the indexed name copies are applicants which pretends to be the main in the form of a queue/stack. This is why: - renaming Suzanne.001 object to Suzanne.002 then it do not swap names - because the lowest number is already occupied by itself. - backward renaming Suzanne.002 object to Suzanne.001 **does** swap names - because this way it pretends to be closer to the main in the queue of applicants. If a scene contains only two objects Suzanne.003 and Suzanne.005, renaming Suzanne.003 into Suzanne.005 returns Suzanne.001 - because it is the lowest available index number in the queue/stack of Suzanne applicants. So: - Renaming Suzanne.003 into Suzanne.005 will return Suzanne.001 - the lowest availbale index in the stack. - Renaming Suzanne.005 into Suzanne.003 will shift the touched elements in the stack. - Duplicating Suzanne.005 object will return Suzanne.001 (not Suzanne.006) - the lowest availbale index in the stack. In this system the ability to rename an indexed applicant into the non-indexed main is essential for clones resolving via proper stack datahandling.

👍 4

kaiwas commented

2024-03-07 07:32:35 +01:00

Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs:

Very bad change!

> Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs: Very bad change!

👍 1

Ilia commented

2024-03-07 08:09:44 +01:00

Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names.

 I also think this change breaks down the process more than fixes it.

There are many cases when Im sure that the particular material "metal.001" is correct and final, and I do not have the opportunity to quickly rename it to "metal", because there is a duplicate somewhere in the scene. It is a special quest to find wrong "metal" material and manually rename it in complicated scene.

At least there is necessary something like "FORCE RENAME" function.

Now renaming works as terrible as in maya

> > Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names. I also think this change breaks down the process more than fixes it. There are many cases when Im sure that the particular material "metal.001" is correct and final, and I do not have the opportunity to quickly rename it to "metal", because there is a duplicate somewhere in the scene. It is a special quest to find wrong "metal" material and manually rename it in complicated scene. At least there is necessary something like "FORCE RENAME" function. Now renaming works as terrible as in maya

👍 2

Ilia commented

2024-03-07 08:14:15 +01:00

Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f5

If rename Suzanne.001 to Suzanne they would swap the names

Also, this was bit consistent. In following file if you rename Suzanne.001 object to Suzanne.002 then it do not swap names.

Not a bug, closing.

for example, you can try to rename this "Building.001" material to "Building". It is possible, but you need to waste extra time

> Hi, thanks for the report. I can replicate. Though this was an intentional change to avoid changing the names of non-selected IDs: 195bb4f8f50df822ff820806edd5a87b5bc9d9da > > If rename Suzanne.001 to Suzanne they would swap the names > > Also, this was bit consistent. In following file if you rename `Suzanne.001` object to `Suzanne.002` then it do not swap names. > > Not a bug, closing. for example, you can try to rename this "Building.001" material to "Building". It is possible, but you need to waste extra time ![изображение](/attachments/be07db24-3afe-47aa-bfea-25f0d1d0c775)

изображение.png

954 KiB

test.blend

4.5 MiB

👍 3

kaiwas commented

2024-03-07 08:15:14 +01:00

If the user wants to assign a specific name to an object, it is assumed that he knows what he is doing and that he really needs it.
Instead of breaking the usual logic, it would be possible to output a message that object "A" was automatically renamed to object "A.001" after the user reassigned the name of the previously existing object "A"

After all, the new option could be an optional option, activated when needed. And not a forced transition to an inconvenient option.

If the user wants to assign a specific name to an object, it is assumed that he knows what he is doing and that he really needs it. Instead of breaking the usual logic, it would be possible to output a message that object "A" was automatically renamed to object "A.001" after the user reassigned the name of the previously existing object "A" After all, the new option could be an optional option, activated when needed. And not a forced transition to an inconvenient option.

👍 1

Pratik Borhade commented

2024-03-07 08:16:44 +01:00

So according to all the comments, silently renaming the non-selected ID was correct behavior? 🙂
Maybe you can check #115192 for details why this fix was made

So according to all the comments, silently renaming the non-selected ID was correct behavior? 🙂 Maybe you can check #115192 for details why this fix was made

Pratik Borhade commented

2024-03-07 08:28:00 +01:00

Explaining the fix 195bb4f8f5 :

You have two objects. Suzanne and Suzanne.001. If rename Suzanne.001 (2) to Suzanne (1) they would swap the names

Lets take this example. In 4.0, if you rename (2) to Suzanne then for a instance two IDs will have same name.
To ensure the new entered name is unique, BLI_libblock_ensure_unique_name function searches for the ID (2) that we just renamed by "name" (i.e. Suzanne). When searching by string, it finds wrong ID (1) and it adds suffix to name (1)

The idea behind the fix is to not silently change the name of "non-selected" IDs

Explaining the fix 195bb4f8f5 : > You have two objects. Suzanne and Suzanne.001. If rename Suzanne.001 (2) to Suzanne (1) they would swap the names Lets take this example. In 4.0, if you rename (2) to `Suzanne` then for a instance two IDs will have same name. To ensure the new entered name is unique, [BLI_libblock_ensure_unique_name](https://projects.blender.org/blender/blender/commit/195bb4f8f50df822ff820806edd5a87b5bc9d9da#diff-d4e6bd0def33c8a567ee616029a4cfcb0eb37dc0) function searches for the ID (2) that we just renamed by "name" (i.e. `Suzanne`). When searching by string, it finds wrong ID (1) and it adds suffix to name (1) - - - The idea behind the fix is to not silently change the name of "non-selected" IDs

kaiwas commented

2024-03-07 08:59:05 +01:00

So according to all the comments, silently renaming the non-selected ID was correct behavior? 🙂
YES!!!
Because I want to rename this particular cube with EXACTLY THIS name. Now I can do it anyway (I will achieve my goal), but now I have to do a lot of extra steps.

Maybe you can check #115192 for details why this fix was made
Quote from there:
"Same happen with images, using bpy (detected in a glTF import process)"
That is, these changes were made so that users of other programs could correctly import their data from some "Maya"?
Stop breaking the correct logic of the blender, which has existed for more than a decade and is very convenient. Let "Maya" users break their old habits!
UPD/ You took as a basis a rather specific problem case with many renamings, and when fixing it, you broke a convenient option that worked correctly for a larger number of tasks. This is not the best way to fix it.

> So according to all the comments, silently renaming the non-selected ID was correct behavior? 🙂 YES!!! Because I want to rename this particular cube with EXACTLY THIS name. Now I can do it anyway (I will achieve my goal), but now I have to do a lot of extra steps. > Maybe you can check #115192 for details why this fix was made Quote from there: "Same happen with images, using bpy (detected in a glTF import process)" That is, these changes were made so that users of other programs could correctly import their data from some "Maya"? Stop breaking the correct logic of the blender, which has existed for more than a decade and is very convenient. Let "Maya" users break their old habits! UPD/ You took as a basis a rather specific problem case with many renamings, and when fixing it, you broke a convenient option that worked correctly for a larger number of tasks. This is not the best way to fix it.

Paul Kotelevets commented

2024-03-07 09:39:46 +01:00

Quotation from the #115192 task:

This last case is bad/dangerous imho, as we are silently renaming some data without let it know to the user.
Here is how to reproduce (seems order of renaming and name choose are important):

On default scene, duplicate the cube.
The new cube is now selected, rename (in Property panel) to "H".
Select the initial cube, rename to "H".
No issue here, the cube renamed automatically to "H.001" - this indicates that element was placed in the H stack which already exists.

Now

Try rename it to "H" again - it will pass, because now you are aware that this name is located in the existing stack, and by additional manual renaming you confirm that you want to turn this particular indexed name from this stack into its non-indexed main.

So with the first rename you place object as a new member into the existing stack, and with second rename you make it main of this stack.

The possible problem of a silent renaming is not in renaming, but in silence, and since you operate with an existing indexed stack member, knowing that such member's stack exists, it cannot be considered silent.

Quotation from the #115192 task: This last case is bad/dangerous imho, as we are silently renaming some data without let it know to the user. Here is how to reproduce (seems order of renaming and name choose are important): 1. On default scene, duplicate the cube. 2. The new cube is now selected, rename (in Property panel) to "H". 3. Select the initial cube, rename to "H". 4. No issue here, the cube renamed automatically to "H.001" - _this indicates that element was placed in the H stack which already exists._ Now 5. Try rename it to "H" **again** - _it will pass, because now you are aware that this name is located in the existing stack, and by additional manual renaming you confirm that you want to turn this particular indexed name from this stack into its non-indexed main._ So with the first rename you place object as a new member into the existing stack, and with second rename you make it main of this stack. The possible problem of a silent renaming is not in renaming, but in silence, and since you operate with an existing indexed stack member, knowing that such member's stack exists, it cannot be considered silent.

Pratik Borhade commented

2024-03-07 09:52:53 +01:00

That is, these changes were made so that users of other programs could correctly import their data from some Maya?
Stop breaking the correct logic of the blender, which has existed for more than a decade and is very convenient. Let Maya users

@kaiwas , I'm not sure why you're relating this fix with Maya.

If old behavior of silently renaming other IDs is useful, we can revert the fix 🤷‍♂️
cc @mont29 @ideasman42

> That is, these changes were made so that users of other programs could correctly import their data from some Maya? Stop breaking the correct logic of the blender, which has existed for more than a decade and is very convenient. Let Maya users @kaiwas , I'm not sure why you're relating this fix with Maya. If old behavior of **silently** renaming other IDs is useful, we can revert the fix 🤷‍♂️ cc @mont29 @ideasman42

kaiwas commented

2024-03-07 10:04:59 +01:00

@kaiwas , I'm not sure why you're relating this fix with Maya.

It could be any other program with some kind of logic of its own. I think that you don’t always need to repeat “how to....” Especially when there is already a better option already here.
I linked it to another program because I saw a mention of the import process via gltf.
It’s just that a lot of “analogies” have already happened when “alien logic” was brought into the program.

If old behavior of silently renaming other IDs is useful, we can revert the fix

Personally, that would suit me. But I also understand that the current behavior has some kind of logic. Perhaps the most correct option would be to do this through an additional activated setting (checkbox). This way, everyone could choose the option that is more convenient for them.
but if this is impossible, then the previous option is much more convenient than the new one. If this caused massive difficulties, then users would have identified this long ago (en masse).

>> @kaiwas , I'm not sure why you're relating this fix with Maya. It could be any other program with some kind of logic of its own. I think that you don’t always need to repeat “how to....” Especially when there is already a better option already here. I linked it to another program because I saw a mention of the import process via gltf. It’s just that a lot of “analogies” have already happened when “alien logic” was brought into the program. >>If old behavior of silently renaming other IDs is useful, we can revert the fix Personally, that would suit me. But I also understand that the current behavior has some kind of logic. Perhaps the most correct option would be to do this through an additional activated setting (checkbox). This way, everyone could choose the option that is more convenient for them. but if this is impossible, then the previous option is much more convenient than the new one. If this caused massive difficulties, then users would have identified this long ago (en masse).

Pratik Borhade commented

2024-03-07 10:16:48 +01:00

Also, the current behavior of 4.1 is consistent with other areas. i.e. renaming UIList and Tree view items (eg: renaming vertex groups, GP layers)

It could be any other program... I linked it to another program because I saw a mention of the import process via gltf.

FYI @JulienDuroure maintains gltf IO code :)

Perhaps the most correct option would be to do this through an additional activated setting (checkbox).

I don't think some checkbox/property is required in preferences to switch between renaming behavior.

If this caused massive difficulties, then users would have identified this long ago (en masse).

#71244

Also, the current behavior of 4.1 is consistent with other areas. i.e. renaming UIList and Tree view items (eg: renaming vertex groups, GP layers) > It could be any other program... I linked it to another program because I saw a mention of the import process via gltf. FYI @JulienDuroure maintains gltf IO code :) > Perhaps the most correct option would be to do this through an additional activated setting (checkbox). I don't think some checkbox/property is required in preferences to switch between renaming behavior. > If this caused massive difficulties, then users would have identified this long ago (en masse). #71244

Bastien Montagne commented

2024-03-07 10:17:55 +01:00

The fix should definitely not be reverted. The old behavior was not always swapping names, end result depended on the respective order of the two colliding IDs in the internal storage. So in some cases names would be swapped, in others the edited name would get the additional .xxx suffix instead. More details can be found in the original design task (#71244).

Adding a way to allow the 'name swapping' behavior, and ensure that it always happen, is considered a TODO currently. There is no clear design (UI/UX wise) as to how to properly present this option to users though.

The fix should definitely _not_ be reverted. The old behavior was not _always_ swapping names, end result depended on the respective order of the two colliding IDs in the internal storage. So in some cases names would be swapped, in others the edited name would get the additional `.xxx` suffix instead. More details can be found in the original design task (#71244). Adding a way to allow the 'name swapping' behavior, and ensure that it always happen, is considered a TODO currently. There is no clear design (UI/UX wise) as to how to properly present this option to users though.

👍 3

Bastien Montagne reopened this issue

2024-03-07 10:17:58 +01:00

Blender Bot added

and removed

labels 2024-03-07 10:18:01 +01:00

Bastien Montagne added

Type