Page MenuHome

Initial implementation of user defined name-number delimiter (proof of concept)
AbandonedPublic

Authored by Mateusz Grzeliński (brezdo) on Sep 12 2018, 10:17 PM.

Details

Reviewers
None
Summary

The pont of this patch

To add ability to change dot as delimiter of new names, example: Cube.001 -> Cube_001

My implementation

  • store name-number delimiter as char in struct UserDef (user preferences)
  • store all allowed delimiters in struct Global
  • modify generating new names algorithm to avoid names like: Cube.001 -> Cube.001_001 ( method check_for_dupid in`library.c`). It can occur when setting for name-number delimiter has been changed.

Problems:

  • not portable: Storing delimiter in UserDef makes it not portable. I tried storing name-number delimiter in scene but it is very hard to implement. (I would need global access to active scene, and possibly breaks idea of using new_id function in library.c)
  • a lot of hard coded dots does not make it easy... Dots are hard coded in almost all naming conventions except for several places like new driver name. Most of them would me replaced with global call, some of them need to replaced with iterating over all allowed delimiters. Maybe we should consider setting for nodes, armatures etc seperately?
  • currently I store allowed names as enum in UserDef and as char[] in Globals. Is there a blender'ish way to avoid putting the same data in 2 places
  • putting enum values as char breaks the convenction. See enum eNameDelimiter in DNA_userdef_tpes.h. Is it acceptable, or I need to find another way?

Why single char, finite choise of delimiters and not user defined string?

  • It reqieres storing delimiter in scene. You must know extension in order for files to be portable. Example: how to treat name like Cube:001 when you don't know delimiter? If you have limited number of delimiters it is obvious.
  • easier to implement in user settings

TODO's (additional possible features):

  • custom number of leading zeros in names, ex: Cube.00002 (?)
  • operator to provide:
    • ability to rename name-number delimiter of existing objects/nodes/stips etc. (refactor every name in file)
    • ability to change number of leading zeros
  • pay special attention to naming in armatures and bones

What I don't know

  • how to set default value for property in UserDef - now it is empty on startup
  • what effect does it has on backwards compability of .blend files

PS

Diff Detail

Repository
rB Blender
Branch
name_number_delimiter (branched from blender2.8)
Build Status
Buildable 2053
Build 2053: arc lint + arc unit

Event Timeline

Mateusz Grzeliński (brezdo) retitled this revision from Initial implementation of user defined name-number delimiter to Initial implementation of user defined name-number delimiter (proof of concept).Sep 12 2018, 10:32 PM
Mateusz Grzeliński (brezdo) edited the summary of this revision. (Show Details)
Mateusz Grzeliński (brezdo) edited the summary of this revision. (Show Details)

Hi Mateusz
While the patch is a nice start, as you mention there are TODO's and issues with mixing multiple delimiters (especially the potential for names like Cube.001_001 when people have their preferences set differently) or complicating the code by searching over possible delimiters (maybe stripping off a suffix when it shouldn't).

It adds some extra complexity / unpredictability for very little gain.

Others may want to comment, but I'd consider this an anti-feature.

Energy would be better spent here optimizing unique name creation which causes problems when duplicating many objects.

In current implementation with finite number of delimiters, the dot, hyphen and underscore are always considered valid delimiters. So copying Cube_001 will never become Cube_001.001, but instead will become Cube.001. Please see small video demo.

Right, then you have a different issues as mentioned already: maybe stripping off a suffix when it shouldn't.

Having behavior remain simple and predictable is an advantage, especially since this is an area of code that can use optimizing, I'm wary of changes that make this more complicated then it might otherwise be.

Python scripts which extract the significant prefix from a name will need updating with more involved logic, or we need an API people need to remember to use.

Consider the hassles developers need to deal with just by having / and \ path separators.

Not to mention possible annoyance if you ever collaborate with someone who uses a different default delimiter.

From what I can see it's adding different conventions without any practical gains.

This is indeed a feature that, even though it might be 'nice to have' ideally, is not really crucial, and will likely backfire in a lot of corner cases and already shady areas (of the top of my head, can think about e.g. Left/Right symmetry handling [bones, vgroups…], linked/appended data, all kind of scripting/addons issues, etc.). Sure all this would be solvable, but that would imply a lot of effort, and probably some annoying bugs at some point or another.

Tanks for the patch, we appreciate the effort you put into it, but we won’t accept it. It’s always a good idea to try to talk about a new idea with core devs, before investing too much time to implement it. ;)

That's ok. My main goal while doing this, was to learn and by the way do something useful. And I have learned a lot.
Anyway, thank you for you time. :)