GPv3: send notifiers and undo push when changing the active layer #110378
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
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
EEVEE & Viewport
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
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
EEVEE & Viewport
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
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#110378
Loading…
Reference in New Issue
No description provided.
Delete Branch "PratikPB2123/blender:gpv3-rna-prop-active-layer-index"
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?
Use RNA to update the active layer and also do an undo
push in
on_activate
function of tree-view. This is nowpossible after recent refactor:
741c684bf6
,2e9bc6373c
Part of: #110133
Some comments.
@ -117,0 +117,4 @@
static int rna_Grease_Pencil_active_layer_index_get(PointerRNA *ptr)
{
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
int val = grease_pencil->layers().first_index(grease_pencil->get_active_layer());
grease_pencil->get_active_layer
can return anullptr
I think in this case we should return something like-1
.@ -117,0 +118,4 @@
{
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
int val = grease_pencil->layers().first_index(grease_pencil->get_active_layer());
printf("something get");
Remove debug print.
@ -117,0 +126,4 @@
{
using namespace blender::bke::greasepencil;
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
blender::Span<const Layer *> layers = grease_pencil->layers();
No need for a local variable for the span.
const Layer *layer = grease_pencil->layers()[value];
is fine.One more comment (my bad).
@ -117,0 +118,4 @@
{
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
if (grease_pencil->get_active_layer() == nullptr) {
My bad, we have a function for this (which reads a bit nicer) ->
has_active_layer()
. Soif (!grease_pencil->has_active_layer()) {
This works well, but I'm a bit unsure about the
active_index
property. It feels like this should be done by setting thelayers.active
layer pointer instead.E.g. setting
layers.active_index
to an invalid index crashes Blender right now.I'd like @JulianEisel opinion here.
Yes, I also thought about that. But guess that would need additional changes in
ui_but_value_set
and other areas to support rna pointer property (I'll make necessary changes).Looks like other list-rows (shapekeys, vertex groups, etc.) are also using same logic of
active_index
.I guess another option is to just call an operator in
on_activate
or just push an undo step and callWM_event_add_notifier
manually.Right, we can do that in
activate or on_activate
function (it will requirecontext
fromtree_row_click_fn
for undo_push and notifiers)Ok, let's wait for @JulianEisel opinion on this :)
We can't use the view item button like this, noted problems in-line. It should use
on_activate()
instead. I think it makes sense to let that take the context, there are a few places that need it already. Note thaton_activate()
can also set the value via RNA and callRNA_property_update()
, instead of copying what that does already.@ -189,6 +189,7 @@ class AbstractTreeViewItem : public AbstractViewItem, public TreeViewItemContain
virtual ~AbstractTreeViewItem() = default;
virtual void build_row(uiLayout &row) = 0;
virtual void add_treerow_button(uiBlock &block);
This is an internal function that does crucial things for the tree-view to work, it should not be
virtual
(making it possible to override and thus break the tree-view). API users would have to be careful to do exactly what the tree-view internals do, which is a big red flag for the API design.And given that it's such a crucial internal function, it should stay
private
as well.@ -170,0 +191,4 @@
UI_but_flag_enable(view_item_but_, UI_BUT_UNDO);
view_item_but_->view_item = reinterpret_cast<uiViewItemHandle *>(this);
view_item_but_->rnaprop = RNA_struct_find_property(&layer_ptr, "active_index");
View item buttons are not designed to control RNA properties. It just happens to work in this case because they reuse
ui_apply_but_ROW()
(which applies the value ofbut->hardmax
which you set to the layer index here). But this is not intentional design and can break easily.@ -117,0 +129,4 @@
{
using namespace blender::bke::greasepencil;
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
const Layer *layer = grease_pencil->layers()[value];
value
should be boundary checked, no change should be done if it's not in the range of valid indices.@ -117,0 +131,4 @@
GreasePencil *grease_pencil = rna_grease_pencil(ptr);
const Layer *layer = grease_pencil->layers()[value];
grease_pencil->set_active_layer(layer);
WM_main_add_notifier(NC_GPENCIL | NA_EDITED, NULL);
Don't send notifiers in a setter, that's what
RNA_def_property_update()
is for.Thanks :)
I'll revert these changes.
I see one problem to solve, exposed by letting
on_activate()
take context.on_activate()
should only be called when actually activating the item through the tree-view, e.g. when clicking on an item. It should not be called when the tree-view just updates its state to reflect external changes, i.e. whenshould_be_active()
starts returning true.I'd propose that I take this over, to fix this and expose context to
on_activate()
.I think this is handled already in
AbstractTreeViewItem::activate
returned early when state is not changed (maybe I'm wrong, haven't checked with breakpoint yet, building... 😅)
Not problem. We can close this PR then
Edit: I see, it is called from other areas too, eg:
change_state_delayed
Okay, I did a number of changes:
dedd55df33
,2e9bc6373c
,741c684bf6
(and more). Context is passed toon_activate()
now, so you can continue with this.@JulianEisel Awesome, thank you 👍
Thanks @JulianEisel :D
GPv3: RNA property to set active layerto GPv3: send notifiers and push when changing the active layerGPv3: send notifiers and push when changing the active layerto GPv3: send notifiers and undo push when changing the active layer@ -184,2 +187,4 @@
void on_activate(bContext &C) override
{
this->grease_pencil_.set_active_layer(&layer_);
WM_event_add_notifier(&C, NC_GPENCIL | ND_DATA | NA_SELECTED, &(this->grease_pencil_));
Passing a value to the
reference
parameter is usually only needed for specific cases, is there any reason your doing this? Otherwise I'd prefer keeping this null, so it's clear that it's not needed (making further refactors to remove the argument easier).Also, thinking about this, I think it's better to use RNA here, so that the message bus also gets notified about the change. Call
RNA_property_pointer_set()
andRNA_property_update()
for this.Code LGTM. Also compiled and tested it. Thanks 👍
Merged, thanks for reviewing :)