blender/blender
148
473
Fork 695
Code Issues 6.7k Pull Requests 907 Projects 18 Wiki Activity

Allow name-swapping in some cases when renaming IDs from the UI #119139

New Issue
Open
opened 2024-03-07 00:45:33 +01:00 by Yegor · 53 comments
Yegor commented 2024-03-07 00:45:33 +01:00
Copy Link

Problem:
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').

Definitions:

  • Suffix: Auto increment .001, .002 added by Blender to solve name clash.
  • Prefix: Everything that goes before .001

Proposal:
The proposal is a mix of the old behaviour and the new one:

  • If there is no name clash: The new name stays.
  • If there is a name clash, and the original name did not share the same prefix: The new name gets the first available suffix.
  • If there is a name clash, and they share the same prefix: The new name stays, the old named element gets the first available suffix.

This is only for UI editing. Similar behaviour will be available via a new API rename function.

WIP implementation: !126996

Testing build: https://builder.blender.org/download/patch/PR126996

Original report:

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.

**Problem:** 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'). **Definitions:** * Suffix: Auto increment .001, .002 added by Blender to solve name clash. * Prefix: Everything that goes before .001 **Proposal:** The proposal is a mix of the old behaviour and the new one: * If there is no name clash: The new name stays. * If there is a name clash, and the original name did not share the same prefix: The new name gets the first available suffix. * If there is a name clash, and they share the same prefix: The new name stays, the old named element gets the first available suffix. This is only for UI editing. Similar behaviour will be available via a new API rename function. WIP implementation: !126996 Testing build: https://builder.blender.org/download/patch/PR126996 --------------------------------- _Original report:_ **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
Severity
Normal
Type
Report
Status
Needs Triage
 labels 2024-03-07 00:45:34 +01:00
Pratik Borhade commented 2024-03-07 04:02:24 +01:00
Member
Copy Link

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
👎 4
Blender Bot added
Status
Archived
 and removed
Status
Needs Triage
 labels 2024-03-07 04:04:00 +01:00
Yegor commented 2024-03-07 04:08:44 +01:00
Author
Copy Link

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

I mean auto swapping names was good and handy...
👍 2
Paul Kotelevets commented 2024-03-07 05:11:08 +01:00
Copy Link

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
Member
Copy Link

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
Copy Link

@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
Copy Link

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
Copy Link

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
Copy Link

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
Copy Link

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
Member
Copy Link

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
Member
Copy Link

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
Copy Link

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
Copy Link

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

  1. 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
Member
Copy Link

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
Copy Link

@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
Member
Copy Link

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
Owner
Copy Link

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.
👍 4
Blender Bot added
Status
Needs Triage
 and removed
Status
Archived
 labels 2024-03-07 10:18:01 +01:00
Bastien Montagne changed title from Autorenaming (swapping names) of object with the same name doesn't work anymore. to Allow name-swapping when renaming IDs from the UI 2024-03-07 10:19:36 +01:00
Paul Kotelevets commented 2024-03-07 10:23:30 +01:00
Copy Link

The reasons why it not always swapped names already has been listed there - it is intentional part of the stack mechanics.
This is why it doesnot swap name at the first attempt in case from my previous comment

  • you can swap stack members only in descending order (an attempt to reach the lower number takes the priority).
  • you can turn to main stack member only one of the other stack members - also in descending order

and it is also intentional part of the naming stack mechanics which makes such a mechanics not silent and makes the result predictable which disallow to corrupt the naming stacks, but allow to operate with them:

изображение

The reasons why it not always swapped names already has been listed there - it is intentional part of the stack mechanics. This is why it doesnot swap name at the first attempt in case from my previous comment - you can swap stack members only in descending order (an attempt to reach the lower number takes the priority). - you can turn to main stack member only one of the other stack members - also in descending order and it is also intentional part of the naming stack mechanics which makes such a mechanics not silent and makes the result predictable which disallow to corrupt the naming stacks, but allow to operate with them: ![изображение](/attachments/7f09a3b9-8d36-47f3-9545-0cf2d86558f4)
изображение.png
114 KiB
👍 5
Bastien Montagne commented 2024-03-07 10:26:09 +01:00
Owner
Copy Link

@pablovazquez @dfelinto @JulianEisel @Harley This is really a UI/UX design issue. Once a good way to handle this is decided, implementing it should be fairly trivial.

@pablovazquez @dfelinto @JulianEisel @Harley This is really a UI/UX design issue. Once a good way to handle this is decided, implementing it should be fairly trivial.
👍 1 ❤️ 2
Bastien Montagne changed title from Allow name-swapping when renaming IDs from the UI to WIP: Allow name-swapping when renaming IDs from the UI 2024-03-07 10:27:13 +01:00
Paul Kotelevets commented 2024-03-07 10:55:49 +01:00
Copy Link

Yes, stack mechanics it is related to UI/UX in the context of a copies datahandling. It allow to flexibly handle copies in a preemptive (displacing) naming system, which itself has lots of advantages by design.

Yes, stack mechanics it is related to UI/UX in the context of a copies datahandling. It allow to flexibly handle copies in a preemptive (displacing) naming system, which itself has lots of advantages by design.
Paul Kotelevets commented 2024-03-07 11:41:15 +01:00
Copy Link

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

I can try to explain if you don't mind.

Any user is represented by attribution (practical area where software is used) and background (other software manuals which was learned).
It is easy to imagine such a result we has got satisfying a Maya user (where naming conventions are rather messy and permissions/restrictions of its system are unbalanced) who opened Blender the very first time and didn't got the mechanics right after several attempts.
For example, 3dsMax user would more likely propose to remove all the restrictions and just allow all the collisions (which also predictably cause lots of problems in Max).
For sure, both systems are incompatible with Blender, which originally followed CAD/engineering software level of data structure clarity by design.

> I'm not sure why you're relating this fix with Maya. I can try to explain if you don't mind. Any user is represented by attribution (practical area where software is used) and background (other software manuals which was learned). It is easy to imagine such a result we has got satisfying a Maya user (where naming conventions are rather messy and permissions/restrictions of its system are unbalanced) who opened Blender the very first time and didn't got the mechanics right after several attempts. For example, 3dsMax user would more likely propose to remove all the restrictions and just allow all the collisions (which also predictably cause lots of problems in Max). For sure, both systems are incompatible with Blender, which originally followed CAD/engineering software level of data structure clarity by design.
Paul Kotelevets commented 2024-03-08 06:41:28 +01:00
Copy Link

Technically, stack mechanics is not a problem, but a solution to the problem which, for example, is not solved in Maya yet, and more likely will never be solved in 3dsmax because of a system design level differentiations. It has simple laws (but not primitive, so it may not be obvious in the beginning) that allow to handle and manage copies in flexible but predictable way.

Therefore, the original report is a cold spot issue that better fits forum question format (I make some operations and getting results that I found weird - why it works like that? ) rather than a bug report, and assumes proper mechanics explanation and design before fixing, otherwise it would be more likely massively reported over all those years by experienced Blender users (who also know Max and Maya pretty deep up to its system design flaws), which is typical for hot spot issues (like, for example, vertex groups being object data level system while mimics mesh data level system issue).

Technically, stack mechanics is not a problem, but a solution to the problem which, for example, is not solved in Maya yet, and more likely will never be solved in 3dsmax because of a system design level differentiations. It has simple laws (but not primitive, so it may not be obvious in the beginning) that allow to handle and manage copies in flexible but predictable way. Therefore, the original report is a cold spot issue that better fits forum question format (_I make some operations and getting results that I found weird - why it works like that?_ ) rather than a bug report, and assumes proper mechanics explanation and design before fixing, otherwise it would be more likely massively reported over all those years by experienced Blender users (who also know Max and Maya pretty deep up to its system design flaws), which is typical for hot spot issues (like, for example, vertex groups being object data level system while mimics mesh data level system issue).
Paul Kotelevets commented 2024-03-09 14:37:42 +01:00
Copy Link

@PratikPB2123 It looks I caught an issue - the problem is that descending order rule also follow outer stack naming, which could be considered as a violation of a non-silent behaviour.

If you have two objects named 2 and 4

  • renaming 2 into 4 (in ascending order) will first add renamed object to stack as 4.001 - which is safe, and the second rename allow to reach 4 which is main of the stack - which is also safe

image

  • renaming 4 into 2 (in descending order) will silently replace main 2 and will shift existing main to 2.001

image

This happens because 2 < 4 and descending order rule, which is useful inside of ID stacks, but is also applied outside of ID stacks, which cause problem.
For sure mixed order-dependent behaviour outside of ID stacks could be confusing, so it better be an option which either allow or disallow direct swapping (will there be 2 or 1 renaming steps needed) of main between ID stacks explicitly, because such a demand is workflow-dependent.

I think that two steps renaming technique from my previous picture could be enough for both directions outside of the ID stacks, since it works pretty flexible and safe in ascending order.

Total blocking of a swapping ability inside of the same ID stack instead of just making it safe in descending order outside of ID stack for sure results in a heavy workflow design issue.

@PratikPB2123 It looks I caught an issue - the problem is that descending order rule also follow outer stack naming, which could be considered as a violation of a non-silent behaviour. If you have two objects named 2 and 4 - renaming 2 into 4 (in ascending order) will first add renamed object to stack as 4.001 - which is safe, and the second rename allow to reach 4 which is main of the stack - which is also safe ![image](/attachments/f1e3ab3d-bafd-42ea-b060-2d43593da25f) - renaming 4 into 2 (in descending order) will silently replace main 2 and will shift existing main to 2.001 ![image](/attachments/3faf4e77-56e1-4f87-a49a-6066bba25c72) This happens because 2 < 4 and descending order rule, which is useful inside of ID stacks, but is also applied outside of ID stacks, which cause problem. For sure mixed order-dependent behaviour outside of ID stacks could be confusing, so it better be an option which either allow or disallow direct swapping (will there be 2 or 1 renaming steps needed) of main between ID stacks explicitly, because such a demand is workflow-dependent. I think that two steps renaming technique from my previous picture could be enough for both directions outside of the ID stacks, since it works pretty flexible and safe in ascending order. Total blocking of a swapping ability inside of the same ID stack instead of just making it safe in descending order outside of ID stack for sure results in a heavy workflow design issue.
image.png
49 KiB
image.png
46 KiB
Paul Kotelevets commented 2024-03-10 07:54:25 +01:00
Copy Link

In short,

  • outside of ID stacks renaming laws should be order-independent - so if you try to access/occupy some other existing ID stack, first renaming should always generate index, which indicates that name has been placed into some existing stack and allow user to make further decision (to push name forward when it is not important or to investigate who ocuppy the name when it is important).
  • inside of ID stack renaming laws should be left as is (order-dependent) - so the second renaming should allow to achieve main ID of the stack according to descending order.

I guess such a solution/conversation may interest @ideasman42, since he also tried to handle this issue.

In short, - outside of ID stacks renaming laws should be order-independent - so if you try to access/occupy some other existing ID stack, first renaming should always generate index, which indicates that name has been placed into some existing stack and allow user to make further decision (to push name forward when it is not important or to investigate who ocuppy the name when it is important). - inside of ID stack renaming laws should be left as is (order-dependent) - so the second renaming should allow to achieve main ID of the stack according to descending order. I guess such a solution/conversation may interest @ideasman42, since he also tried to handle this issue.
❤️ 1
Jose Conseco commented 2024-03-14 23:10:47 +01:00
Copy Link

Half of my plugins are broken due to this name swap lock. If the change wont be reverted (and it seems it wont), then pls. add info about it to python api changes, so that addon devs can properly update then plugins for b4.1 .

Also - at least now in Blender 4.1 rename, is consistent - always blocks name swap, is name is already taken
Old way was worse - since in some cases it would allow to swap name, in some it would not (depending on stack order shown above)

I guess I we want to swap name in b4.1 the we will have to:

a_temp  =  a_id.name
b_temp  =  b_id.name
a_id.name = ' random_available_name'  # free up 'a_temp' name (no id is using it now)
b_id.name = a_temp,                                  # so use it   (no collision thx. to line above)
a_id.name = b_temp                   # finish swap.  'b_temp' is no longer used (line above)  so  should work.

In the end, IMO it is just matter of :
a ) always allow swap
b) or - never allow swap, if name is taken.

Half of my plugins are broken due to this name swap lock. If the change wont be reverted (and it seems it wont), then pls. add info about it to python api changes, so that addon devs can properly update then plugins for b4.1 . Also - at least now **in Blender 4.1 rename, is consistent - always blocks name swap, is name is already taken** Old way was worse - since in some cases it would allow to swap name, in some it would not (depending on stack order shown above) I guess I we want to swap name in b4.1 the we will have to: ``` a_temp = a_id.name b_temp = b_id.name a_id.name = ' random_available_name' # free up 'a_temp' name (no id is using it now) b_id.name = a_temp, # so use it (no collision thx. to line above) a_id.name = b_temp # finish swap. 'b_temp' is no longer used (line above) so should work. ``` In the end, IMO it is just matter of : a ) always allow swap b) or - never allow swap, if name is taken.
Alaska removed the
Status
Confirmed
Severity
Normal
 labels 2024-04-07 06:25:38 +02:00
Apois-Levy commented 2024-04-08 10:11:16 +02:00
Copy Link

I second the oppinion, that this change was uneccesary and takes away neat functionality that seems to have worked "perfectly fine" in the past. When iterating, its quite common to duplicate an item over and over and keep working on it- by disallowing the swap, it makes renaming your current worked on item quite tedious.

This is even worse when trying to do the same with materials- who are not as easy to access- and having to manually rename the material that is, effectively, meant to be "discarded".

I second the oppinion, that this change was uneccesary and takes away neat functionality that seems to have worked "perfectly fine" in the past. When iterating, its quite common to duplicate an item over and over and keep working on it- by disallowing the swap, it makes renaming your current worked on item quite tedious. This is even worse when trying to do the same with materials- who are not as easy to access- and having to manually rename the material that is, effectively, meant to be "discarded".
Luis Miguel Maldonado commented 2024-04-09 15:59:30 +02:00
Copy Link

Thank you for working on Blender's development. However, is there no way to undo this? Or better yet, could the option to enable/disable it be implemented in Blender's Preferences?

Thank you for working on Blender's development. However, is there no way to undo this? Or better yet, could the option to enable/disable it be implemented in Blender's Preferences?
Sergei Sobolev commented 2024-04-11 14:21:34 +02:00
Copy Link

Please return the old system or

make a pop-up window with an option to rename what I want to and offer to rename the object with the original name. And if the object/material/any other data-block deleted from the scene offer to delete data and transfer the desirable name to the object that I am trying to rename.

I am pretty sure you can invent hundreds of other ways to solve the problem and give us a friendly user experience. Or give us back what you have taken for no reason.

Now I am struggling to work with big scenes, with materials and meshes. It is a real pain. Please hear us.

Please return the old system or make a pop-up window with an option to rename what I want to and offer to rename the object with the original name. And if the object/material/any other data-block deleted from the scene offer to delete data and transfer the desirable name to the object that I am trying to rename. I am pretty sure you can invent hundreds of other ways to solve the problem and give us a friendly user experience. Or give us back what you have taken for no reason. Now I am struggling to work with big scenes, with materials and meshes. It is a real pain. Please hear us.
👍 3
Vyacheslav Kobozev commented 2024-04-11 16:55:38 +02:00
Copy Link

Previous renaming was special but sane: if Name occupied, then renaming to Name produces Name.001 first. But if i insist, blender flips names. That was pretty simple.
Soo if you, dear developers, want to change it, please find another simple solution with same amount of button clicks or fewer.

Previous renaming was special but sane: if Name occupied, then renaming to Name produces Name.001 first. But if i insist, blender flips names. That was pretty simple. Soo if you, dear developers, want to change it, please find another simple solution with same amount of button clicks or fewer.
👍 3
Bastien Montagne commented 2024-04-11 17:30:42 +02:00
Owner
Copy Link

Please read what was already said (multiple times!) above regarding the previous system's behavior.

Also, this is not a forum thread. Design tasks cluttered with noise are way more painful to work on - and way more likely to be 'forgotten' forever because of that.

Until this task gets a proper proposal and is not WIP anymore, please refrain to comment, unless you are actively working on this design and have constructive, realistic and well-informed contributions to make.

Please read what was already said (multiple times!) above regarding the previous system's behavior. Also, this is not a forum thread. Design tasks cluttered with noise are way more painful to work on - and way more likely to be 'forgotten' forever because of that. Until this task gets a proper proposal and is not WIP anymore, please refrain to comment, unless you are actively working on this design and have constructive, realistic and well-informed contributions to make.
👍 2
kaiwas commented 2024-04-16 22:53:57 +02:00
Copy Link

Please read what was already said (multiple times!) above regarding the previous system's behavior.

Also, this is not a forum thread. Design tasks cluttered with noise are way more painful to work on - and way more likely to be 'forgotten' forever because of that.

Until this task gets a proper proposal and is not WIP anymore, please refrain to comment, unless you are actively working on this design and have constructive, realistic and well-informed contributions to make.

This new solution is just a piece of garbage. And you don't know how to fix everything. Just admit it!
At the very least, stop silencing dissatisfied people. They have the right to be indignant, because the introduced innovation makes working with the program worse.
The novelty might just be an option.

It’s good that there is version 4.0 without these stupid innovations with renaming and autosmooth. This is what I plan to use in the future.
You can do nothing more and disband the team.

This is regression

> Please read what was already said (multiple times!) above regarding the previous system's behavior. > > Also, this is not a forum thread. Design tasks cluttered with noise are way more painful to work on - and way more likely to be 'forgotten' forever because of that. > > Until this task gets a proper proposal and is not WIP anymore, please refrain to comment, unless you are actively working on this design and have constructive, realistic and well-informed contributions to make. > > This new solution is just a piece of garbage. And you don't know how to fix everything. Just admit it! At the very least, stop silencing dissatisfied people. They have the right to be indignant, because the introduced innovation makes working with the program worse. The novelty might just be an option. It’s good that there is version 4.0 without these stupid innovations with renaming and autosmooth. This is what I plan to use in the future. You can do nothing more and disband the team. This is regression
👎 1
Thomas Dinges commented 2024-04-17 10:50:00 +02:00
Owner
Copy Link

@kaiwas There is no need to insult people here, and we have a clear code of conduct. https://developer.blender.org/docs/handbook/communication/code_of_conduct/

Bastien explained the situation and status already, please respect that and refrain from further off-topic comments here, these don't add to a solution.

@kaiwas There is no need to insult people here, and we have a clear code of conduct. https://developer.blender.org/docs/handbook/communication/code_of_conduct/ Bastien explained the situation and status already, please respect that and refrain from further off-topic comments here, these don't add to a solution.
kaiwas commented 2024-04-17 12:15:29 +02:00
Copy Link

@kaiwas There is no need to insult people here,

Where did you see anyone being insulted?
I talked about the decisions made and innovation. This does not concern anyone personally.

I understand that you may not like what is said in this topic, but the fact remains a fact. The program has gotten worse (I’m not the only one with this opinion).
And all you need to do is return everything to its previous level. But it turns out that for this you need to admit the mistakes you have made (and this is the most difficult thing).

Before radically changing some established approaches, it was necessary to think and analyze three times. But this is not important - the main thing is to do something and pass it off as a feature (sarcasm).

Bastien explained the situation and status already, please respect that and refrain from further off-topic comments here, these don't add to a solution.

Of course this does not contribute to the solution. And most likely it will not be resolved, because I did not see in this thread that the new situation was recognized by the developers as an “Error”. (at first glance they are satisfied with everything).
The developers will simply take a long pause until everyone gets used to it and everything is forgotten. (there are already many such examples)

> @kaiwas There is no need to insult people here, Where did you see anyone being insulted? I talked about the decisions made and innovation. This does not concern anyone personally. I understand that you may not like what is said in this topic, but the fact remains a fact. The program has gotten worse (I’m not the only one with this opinion). And all you need to do is return everything to its previous level. But it turns out that for this you need to admit the mistakes you have made (and this is the most difficult thing). Before radically changing some established approaches, it was necessary to think and analyze three times. But this is not important - the main thing is to do something and pass it off as a feature (sarcasm). > Bastien explained the situation and status already, please respect that and refrain from further off-topic comments here, these don't add to a solution. Of course this does not contribute to the solution. And most likely it will not be resolved, because I did not see in this thread that the new situation was recognized by the developers as an “Error”. (at first glance they are satisfied with everything). The developers will simply take a long pause until everyone gets used to it and everything is forgotten. (there are already many such examples)
Thomas Dinges commented 2024-04-17 12:46:09 +02:00
Owner
Copy Link

You made your point, I will not repeat myself. This task is for developers working on this and not a forum. I will delete any further off-topic comment.

You made your point, I will not repeat myself. This task is for developers working on this and not a forum. I will delete any further off-topic comment.
👍 1
Rincewind commented 2024-04-26 07:17:45 +02:00
Copy Link

I just run also in the new behaviour and I have to agree that the old behaviour was more handy and logical from a user point of view.

Hopefully we get the old behaviour back in 4.2

I just run also in the new behaviour and I have to agree that the old behaviour was more handy and logical from a user point of view. Hopefully we get the old behaviour back in 4.2
Paul Kotelevets commented 2024-04-26 17:48:39 +02:00
Copy Link

Technically, no, it wasnt - the initial behaviour during transition of a name between id stacks could be considered as messy (for example, direction-dependent naming approach in that case is weak against homoglyphs, which make the direction hard to predict) so developers made the right step. But it had a good part - like the ability to resolve name duplicates inside the same id stack.

The problem is that current step is not functionally complete and require enhancement in the area of working inside of the same id stack.

So the next logical step will be not reverting to the previous state, but enhancing the current one.

Technically, no, it wasnt - the initial behaviour during transition of a name between id stacks could be considered as messy (for example, direction-dependent naming approach in that case is weak against homoglyphs, which make the direction hard to predict) so developers made the right step. But it had a good part - like the ability to resolve name duplicates inside the same id stack. The problem is that current step is not functionally complete and require enhancement in the area of working inside of the same id stack. So the next logical step will be not reverting to the previous state, but enhancing the current one.
👍 2
Andrej commented 2024-04-27 14:53:05 +02:00
Contributor
Copy Link

It seems there should be a thread on https://devtalk.blender.org/c/feature-design-feedback/30 (not sure who can create threads on devtalk forum, probably, only developers) that will be linked in this issue to move the community discussion there instead of using bug tracker for this.

It seems there should be a thread on https://devtalk.blender.org/c/feature-design-feedback/30 (not sure who can create threads on devtalk forum, probably, only developers) that will be linked in this issue to move the community discussion there instead of using bug tracker for this.
Paul Kotelevets commented 2024-04-29 02:00:39 +02:00
Copy Link

In short, prevous behavior was bad between id stacks, but good inside the id stack, which allowed to reconcile name duplications.
The current one is good between id stack, but is bad inside the id stack.
It is possible to design the unified solution which works good in both cases - between id stacks and inside the id stack.

I guess thread on devtalk could possibly help to analyse mechanics, what exactly was there good and what exactly caused issues.

In short, prevous behavior was bad between id stacks, but good inside the id stack, which allowed to reconcile name duplications. The current one is good between id stack, but is bad inside the id stack. It is possible to design the unified solution which works good in both cases - between id stacks and inside the id stack. I guess thread on devtalk could possibly help to analyse mechanics, what exactly was there good and what exactly caused issues.
Vyacheslav Kobozev commented 2024-08-08 12:44:27 +02:00
Copy Link

Okay. Mention.
You, developers, tried a new approach. It works worse and breaks pipelines without any comfortable replacement of mechanic.
So please revert back and try again. Also ask ppl, who really work deep (for money, for salary) with Blender.

When you decide that something works well with three cubes in the scene — it is far from real practice.
For example, Geometry nodes module feels very well, partially because ppl like Simon Thomas or Erindale are close to the development and can suggest something, that would work with real and complex cases.

So please listen carefully, what Paul say. He is very skillfull man, who dives deep.

Okay. Mention. You, developers, tried a new approach. It works worse and breaks pipelines without any comfortable replacement of mechanic. So please revert back and try again. Also ask ppl, who really work deep (for money, for salary) with Blender. When you decide that something works well with three cubes in the scene — it is far from real practice. For example, Geometry nodes module feels very well, partially because ppl like Simon Thomas or Erindale are close to the development and can suggest something, that would work with real and complex cases. So please listen carefully, what Paul say. He is very skillfull man, who dives deep.
👍 1
Vyacheslav Kobozev commented 2024-08-08 13:02:04 +02:00
Copy Link

Solution:
When there is name collision after renaming, by default blender shows pop-up with buttons:
«blah-blah-name collision»… [Protect] (default) or [Swap]
And the checkbox «remember my choice and do not ask again».

Solution: When there is name collision after renaming, by default blender shows pop-up with buttons: «blah-blah-name collision»… [Protect] (default) or [Swap] And the checkbox «remember my choice and do not ask again».
👍 1
Dalai Felinto commented 2024-08-27 13:04:35 +02:00
Owner
Copy Link

Task updated with a proposal. @mont29 will work on a build for people to test it and give feedback.

Task updated with a proposal. @mont29 will work on a build for people to test it and give feedback.
Bastien Montagne changed title from WIP: Allow name-swapping when renaming IDs from the UI to Allow name-swapping in some cases when renaming IDs from the UI 2024-08-28 11:22:52 +02:00
Bastien Montagne commented 2024-08-30 22:04:40 +02:00
Owner
Copy Link

A testing build is now available here: https://builder.blender.org/download/patch/PR126996

A testing build is now available here: https://builder.blender.org/download/patch/PR126996
👍 2
Paul Kotelevets commented 2024-09-02 07:30:40 +02:00
Copy Link

Briefly tested windows build.
In general mechanics implemented well, for obname and meshname (in outliner and object properties) it works smoothly

  • in case of a collision between IDs the first renaming gives an index which fills the gap in both accending and descending naming order- which is safe.
  • and the second renaming with manually removing the index in the same ID allow to reach the main ID - which is flexible and safe since allow to achieve predictable expected result.

For materials the mechanics is supported partially - in name field double renaming with manual index removal works, but in the list it doesnot.

image
Briefly tested windows build. In general mechanics implemented well, for obname and meshname (in outliner and object properties) it works smoothly - in case of a collision **between IDs** the first renaming gives an index which fills the gap in both accending and descending naming order- which is safe. - and the second renaming with manually removing the index **in the same ID** allow to reach the main ID - which is flexible and safe since allow to achieve predictable expected result. For materials the mechanics is supported partially - in name field double renaming with manual index removal works, but in the list it doesnot. <img width="735" alt="image" src="attachments/050ea2a5-5de8-429b-b5af-209037e34493">
image.png
92 KiB
Paul Kotelevets commented 2024-09-02 14:49:45 +02:00
Copy Link

There is the other mechanics in material list - pasting a name from clipboard into material's slot name (by hovering a mouse over the required slot and pressing ctrl+V - without entering a name editing).
At the moment if to paste occupied name from clipboard (for example, letter "F") into ASD, it will create an index, which is correct.
But the double pasting doesnot pass in the list, but passes in ithe name field.
It might be worth unifying the behavior to make the double insert mechanic also available in the list.

image

Also for F2-key renaming function manual index removal mechanics doesnot seems to work yet

image
There is the other mechanics in material list - pasting a name from clipboard into material's slot name (by hovering a mouse over the required slot and pressing ctrl+V - without entering a name editing). At the moment if to paste occupied name from clipboard (for example, letter "F") into ASD, it will create an index, which is correct. But the double pasting doesnot pass in the list, but passes in ithe name field. It might be worth unifying the behavior to make the double insert mechanic also available in the list. <img width="1047" alt="image" src="attachments/588f748d-7519-4b5c-959c-72eba30667be"> Also for F2-key renaming function manual index removal mechanics doesnot seems to work yet <img width="536" alt="image" src="attachments/5057ceab-0075-4fe1-ae29-c9c6baac87be">
image.png
59 KiB
image.png
134 KiB
Bastien Montagne commented 2024-09-02 17:55:06 +02:00
Owner
Copy Link

@1D_Inc Thanks for the testing! The two issues are related - we are going to have to find a way to edit ID names from generic UI code :|

@1D_Inc Thanks for the testing! The two issues are related - we are going to have to find a way to edit ID names from generic UI code :|
Bastien Montagne commented 2024-09-02 19:51:15 +02:00
Owner
Copy Link

OK, issue with UILists (and potentially other places where ID.name would be exposed in the UI as a regular property) should be fixed in the branch, triggered new builds, they should be available in a couple of hours max.

OK, issue with UILists (and potentially other places where `ID.name` would be exposed in the UI as a regular property) should be fixed in the branch, triggered new builds, they should be available in a couple of hours max.
Paul Kotelevets commented 2024-09-03 07:48:30 +02:00
Copy Link

Briefly tested the build.
For Collections, Material list and F2 renamer the double rename mechanics works smoothly, feels very nice.
For the attributes like UV the mechanics doesnot work, but from my experience it never worked there ever (checked 2.79).
Might worth a research.

image
Briefly tested the build. For Collections, Material list and F2 renamer the double rename mechanics works smoothly, feels very nice. For the attributes like UV the mechanics doesnot work, but from my experience it never worked there ever (checked 2.79). Might worth a research. <img width="252" alt="image" src="attachments/03bb32dd-5871-4735-ae76-98d7a7dafa02">
image.png
20 KiB
Bastien Montagne commented 2024-09-03 10:12:21 +02:00
Owner
Copy Link

Thanks for testing!

Non-ID names that also need to be unique indeed use a different code-path than IDs (attributes, bones, modifiers, constraints, etc.). While unifying the UI-based behavior with ID renaming could be nice, I would not consider it as part of this design task.

Thanks for testing! Non-ID names that also need to be unique indeed use a different code-path than IDs (attributes, bones, modifiers, constraints, etc.). While unifying the UI-based behavior with ID renaming could be nice, I would not consider it as part of this design task.
👍 1
Dalai Felinto commented 2024-09-03 15:24:07 +02:00
Owner
Copy Link

@mont29 I was talking to @pablovazquez and he suggested to have a message on the status bar when it fails to rename (or when it end up swapping the name with an existent element). Is it even possible?

@mont29 I was talking to @pablovazquez and he suggested to have a message on the status bar when it fails to rename (or when it end up swapping the name with an existent element). Is it even possible?
Pablo Vazquez commented 2024-09-03 15:41:45 +02:00
Member
Copy Link

What I meant is something to hint about trying again to actually rename.

So an "INFO" type report, with the text along the lines of:

  1. Name is in use. Try again to attempt to force a rename. (more vague in case it doesn't work?)
  2. Name is in use. Try again to force a rename.
  3. Name is in use. Retrying forces a rename.
  4. Name is taken. Try again to force-rename.
What I meant is something to hint about trying again to actually rename. So an "INFO" type report, with the text along the lines of: 1. `Name is in use. Try again to attempt to force a rename.` (more vague in case it doesn't work?) 2. `Name is in use. Try again to force a rename.` 3. `Name is in use. Retrying forces a rename.` 4. `Name is taken. Try again to force-rename.`
Bastien Montagne commented 2024-09-03 19:56:11 +02:00
Owner
Copy Link

Added unittests for the new behaviors, and some UI report when renaming either falls back to adjusted (numeric prefix) name, or forces renaming another ID.

New builds started, should be available in a few hours at https://builder.blender.org/download/patch/PR126996

Added unittests for the new behaviors, and some UI report when renaming either falls back to adjusted (numeric prefix) name, or forces renaming another ID. New builds started, should be available in a few hours at https://builder.blender.org/download/patch/PR126996
👍 1
Julien Duroure commented 2024-09-04 15:48:13 +02:00
Member
Copy Link

I just tested that we don't have any regression on bpy.
Seems this is OK

Tested with both:

I just tested that we don't have any regression on bpy. Seems this is OK Tested with both: - code from #115192 - glTF import initial report: https://github.com/KhronosGroup/glTF-Blender-IO/issues/2038
Bastien Montagne commented 2024-09-04 16:28:30 +02:00
Owner
Copy Link

@JulienDuroure thanks! Indeed standard renaming using the ID.name property from BPY should behave exactly as before this PR.

@JulienDuroure thanks! Indeed standard renaming using the `ID.name` property from BPY should behave exactly as before this PR.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
Backward and forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Viewport & EEVEE

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Module
Viewport & EEVEE

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Severity
High

  
Severity
Low

  
Severity
Normal

  
Severity
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
17 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#119139
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?