With the development of GP 3.0 now starting, I ran into a naming issue that I need to be addressed.
In the current grease pencil
"grease_pencils". And this is the only place where it clashes with the new naming I’d like to use for GP 3.0 (explicitly writing out “grease pencil” instead of e.g. “gpencil”/“gpd”, etc.).
I am not sure what
plural_name to use for the new ID data type.
EDIT: I guess one possible idea (albeit ugly) is to discard the underscore and use
This string is used by
BKE_idtype_idcode_to_name_plural. And this is used by the python API (
bpy.data.grease_pencils...) as well as the linking code. So there is probably not a way to reuse the same name, especially since we expect both the old and the new ID to exist for at least some versions.
@brecht @sergey @mont29 @ideasman42
I’m not sure what you mean be usage in the linking code? The Python API for linking in
Another way would be to name it
grease_pencils_new and then rename to
grease_pencils when the old data structures get removed. That would be an API break for this experimental feature, but it would happen as the same time as breaking the old grease pencil API so maybe it’s not so bad.
Maybe I misunderstood Bastien, but I believe the “path” into a blend file to an ID is also using this
I’d be fine with naming it
grease_pencils_new. I think we need a general plan on how to name this new object in general without running into the same name clashes all over (like in the UI also).
Ah, I could not find anything like that grepping for
“New” could work, or “Experimental” and
grease_pencils_experimental. I guess this would mainly be shown when the experimental feature is enabled, as we did for the pointcloud/hair/volume databocks before.
If the plan is to leave the new grease pencil in experimental until we can fully deprecated the old then I guess this can work. This would probably mean that there won’t be a 4.0 release with the new grease pencil though.
I assumed making it non-experimental and removing the old one would be done at the same time. I’m not sure that we should have a Blender release where both are officially supported? The UI could be messy, add-ons would need to support both or confusingly only work for one or the other.
I agree with this, yes. Having both would be messy. I think the idea of them being both in a version was that it would nice to have in a big release like 4.0 (with maybe not full coverage of the features of the old GP). But yes, that does not seem like a good plan if we then have to support two python APIs, versioning, etc., etc. So if we don’t get to feature parity by 4.0, I would be fine with waiting for later (5.0 probably).
Will that mean waiting for 2 years plus according to
The goal is to have
- A new LTS release every year, supported for two years (just as it is currently, but released around the same time of the year).
- A major version and breaking release every 2 years (3.0, 4.0, 5.0…).
In 5.0 is when we would break compatibility. The tool itself will be available as an experimental feature in the daily builds.
I think we can figure out a way to get this ready for 4.0, dragging along the old grease pencil data structures all the way to 5.0 comes with a cost too.
We have to keep in mind though that the old grease pencil structures have to remain anyways because they are used by the annotations. But we might be able to make them explicitly about annotations and deprecate all the functionality related to grease pencil only.
Regarding name usage, the linking code is using the
name_plural (so e.g. you refer to a
Monkey object in
This path representation is used at least in the File Browser, and as path passed to the link/append operators.