Fix #111169: PointerProperty ignores poll function when setting value #111189

Closed
Philipp Oeser wants to merge 1 commits from lichtwerk/blender:111169 into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

According to docs, a pointer PointerProperty poll function should
"determine whether an item is valid for this property".
This was only used for filtering in the UI templates though, setting
(e.g. from python) ignored this entirely.

There was a comment about this in code (so I assume this was somewhat
known), however there doesnt seem to be a reason not to run the poll
when setting the value as well afaict.

Report was about python defined ID properties, but this was also true for
other properties.

For example, you could run the following (even though
rna_Brush_imagetype_poll explicitly forbids this)

image = D.images['Render Result']
brush = D.brushes['Clone']
brush.clone_image = image

So now run the poll in RNA_property_pointer_set (this should not be
performance critical since pointers cannot be animated).

Alternatively, we could have the "set" callback that would be
capable of "determine whether an item is valid for this property" for python
defined properties as well (regular RNA_def_property_pointer_funcs have this,
but then again "poll" actually seems like the right place for this already).

According to docs, a pointer PointerProperty poll function should "determine whether an item is valid for this property". This was only used for filtering in the UI templates though, setting (e.g. from python) ignored this entirely. There was a comment about this in code (so I assume this was somewhat known), however there doesnt seem to be a reason not to run the poll when setting the value as well afaict. Report was about python defined ID properties, but this was also true for other properties. For example, you could run the following (even though `rna_Brush_imagetype_poll` explicitly forbids this) ``` image = D.images['Render Result'] brush = D.brushes['Clone'] brush.clone_image = image ``` So now run the poll in `RNA_property_pointer_set` (this should not be performance critical since pointers cannot be animated). Alternatively, we could have the "set" callback that would be capable of "determine whether an item is valid for this property" for python defined properties as well (regular `RNA_def_property_pointer_funcs` have this, but then again "poll" actually seems like the right place for this already).
Philipp Oeser added 1 commit 2023-08-16 17:00:35 +02:00
Fix #111169: PointerProperty ignores poll function when setting value
Some checks reported errors
buildbot/vexp-code-patch-coordinator Build done.
e8301b0ab8
According to docs, a pointer PointerProperty poll function should
"determine whether an item is valid for this property".
This was only used for filtering in the UI templates though, setting
(e.g. from python) ignored this entirely.

There was a comment about this in code (so I assume this was somewhat
known), however there doesnt seem to be a reason not to run the poll
when setting the value as well afaict.

Report was about python defined ID properties, but this was also true for
other properties.

For example, you could run the following (even though
`rna_Brush_imagetype_poll` explicitly forbids this)
```
image = D.images['Render Result']
brush = D.brushes['Clone']
brush.clone_image = image
```

So now run the poll in `RNA_property_pointer_set`.

Alternatively, we could introduce a separate "set" method that would be
capable of "determine whether an item is valid for this property" (but
then again "poll" actually seems like the right place for this already).
Philipp Oeser added this to the Python API project 2023-08-16 17:00:46 +02:00
Philipp Oeser requested review from Campbell Barton 2023-08-16 17:00:55 +02:00
Philipp Oeser requested review from Bastien Montagne 2023-08-16 17:01:03 +02:00

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR111189) when ready.
Bastien Montagne reviewed 2023-08-25 11:16:47 +02:00
Bastien Montagne left a comment
Owner

LGTM in principal. But I (very) vaguely seem to remember that there was a reason for the current behavior, and the comment in the rna_internal_types.h also seems to imply that the poll function only has very restricted usages.

@ideasman42 @brecht maybe you guys remember better the rational behind current behavior?

LGTM in principal. But I (very) vaguely seem to remember that there was a reason for the current behavior, and the comment in the `rna_internal_types.h` also seems to imply that the poll function only has very restricted usages. @ideasman42 @brecht maybe you guys remember better the rational behind current behavior?

I'd rather not have poll used for checking if a value can be set for a few reasons.

  • If setting a value would cause an error (such as creating a loop in the parent/child relationships), I think it's better this is enforced by the set function, this is already the convention and I find it works well.
  • Poll functions may do slower look-ups which can be OK in the context of a UI, but could slow down scripts.
  • Since poll may fail for existing values, using poll to reject assignment means it's not necessarily possible to temporarily override a value & restore it, because restoring the value will fail if the poll function fails.

So I rather keep poll as advice which works usefully for a UI filter, but keep the "set" callback as the function which can reject an assignment.

I'd rather not have poll used for checking if a value can be set for a few reasons. - If setting a value would cause an error (such as creating a loop in the parent/child relationships), I think it's better this is enforced by the set function, this is already the convention and I find it works well. - Poll functions may do slower look-ups which can be OK in the context of a UI, but could slow down scripts. - Since poll may fail for existing values, using poll to reject assignment means it's not necessarily possible to temporarily override a value & restore it, because restoring the value will fail if the poll function fails. So I rather keep poll as advice which works usefully for a UI filter, but keep the "set" callback as the function which can reject an assignment.
Author
Member

I'd rather not have poll used for checking if a value can be set for a few reasons.

  • If setting a value would cause an error (such as creating a loop in the parent/child relationships), I think it's better this is enforced by the set function, this is already the convention and I find it works well.
  • Poll functions may do slower look-ups which can be OK in the context of a UI, but could slow down scripts.
  • Since poll may fail for existing values, using poll to reject assignment means it's not necessarily possible to temporarily override a value & restore it, because restoring the value will fail if the poll function fails.

So I rather keep poll as advice which works usefully for a UI filter, but keep the "set" callback as the function which can reject an assignment.

That would mean exposing "set" for PointerProperty, right? (atm. this is not available)

> I'd rather not have poll used for checking if a value can be set for a few reasons. > > - If setting a value would cause an error (such as creating a loop in the parent/child relationships), I think it's better this is enforced by the set function, this is already the convention and I find it works well. > - Poll functions may do slower look-ups which can be OK in the context of a UI, but could slow down scripts. > - Since poll may fail for existing values, using poll to reject assignment means it's not necessarily possible to temporarily override a value & restore it, because restoring the value will fail if the poll function fails. > > So I rather keep poll as advice which works usefully for a UI filter, but keep the "set" callback as the function which can reject an assignment. That would mean exposing "set" for `PointerProperty`, right? (atm. this is not available)

I agree with the points Campbell made.

I would not do anything here at all and consider this not a bug. Any conditions that a poll/set function checks can be violated afterwards by modifying the datablock that is being pointed to.

I agree with the points Campbell made. I would not do anything here at all and consider this not a bug. Any conditions that a poll/set function checks can be violated afterwards by modifying the datablock that is being pointed to.
Author
Member

I would not do anything here at all and consider this not a bug. Any conditions that a poll/set function checks can be violated afterwards by modifying the datablock that is being pointed to.

Fine with that, I can close #111169 referring to the discussion here. However:

I think it's better this is enforced by the set function, this is already the convention and I find it works well.

I am confused, set is not available for PointerProperty?

> I would not do anything here at all and consider this not a bug. Any conditions that a poll/set function checks can be violated afterwards by modifying the datablock that is being pointed to. Fine with that, I can close #111169 referring to the discussion here. However: >I think it's better this is enforced by the set function, this is already the convention and I find it works well. I am confused, `set` is not available for `PointerProperty`?
Author
Member

OK, coming back to this I think we can close this try at a solution.

I have been asking the following before, and it looks to me that when you want this kind of control over python-defined properties, you would need the set callback [which at the moment of writing is not available for PointerProperty]:

Alternatively, we could have the "set" callback that would be
capable of "determine whether an item is valid for this property" for python
defined properties as well

That would mean exposing "set" for PointerProperty, right? (atm. this is not available)

I am confused, set is not available for PointerProperty?

OK, coming back to this I think we can close this try at a solution. I have been asking the following before, and it looks to me that when you want this kind of control over python-defined properties, you would need the `set` callback [which at the moment of writing is not available for PointerProperty]: > Alternatively, we could have the "set" callback that would be capable of "determine whether an item is valid for this property" for python defined properties as well > That would mean exposing "set" for PointerProperty, right? (atm. this is not available) > I am confused, set is not available for PointerProperty?
Philipp Oeser closed this pull request 2023-12-29 14:56:24 +01:00
Some checks reported errors
buildbot/vexp-code-patch-coordinator Build done.

Pull request closed

Sign in to join this conversation.
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
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
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
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
5 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#111189
No description provided.