Extending python handlers #48601

New Issue

Alexander Romanov · 2016-06-07T16:45:13+02:00

Alexander Romanov commented

2016-06-07 16:45:13 +02:00

A large part of Blender logic is implemented through operators' calls. And sometime it is necessary to handle such events.

For Blend4Web this feature is important more for user usability now. For example adding new custom node tree for Logic Editor in Blend4Web needs some handle (set this tree as default). And we also have some custom properties that could be set automatically after some event.

I've made an attempt to solve this issue here D2052. Hooks are implemented for all Blender operators, and such freedom can bring bad consequences, first of all in performance.

I see the following ways for improvements:

Make filters on C side to invoke the method for specific operators only.
Make another handler system for operators only (where callbacks are stored in the list inside the concrete operator type), and keep the current system for high level events like "Select Object" that could include a set of events: (object_ ... create / delete / select / hide / reveal / mode_change ... _pre / _post).

A large part of Blender logic is implemented through operators' calls. And sometime it is necessary to handle such events. For Blend4Web this feature is important more for user usability now. For example adding new custom node tree for Logic Editor in Blend4Web needs some handle (set this tree as default). And we also have some custom properties that could be set automatically after some event. I've made an attempt to solve this issue here [D2052](https://archive.blender.org/developer/D2052). Hooks are implemented for all Blender operators, and such freedom can bring bad consequences, first of all in performance. I see the following ways for improvements: 1) Make filters on C side to invoke the method for specific operators only. 2) Make another handler system for operators only (where callbacks are stored in the list inside the concrete operator type), and keep the current system for high level events like "Select Object" that could include a set of events: (object_ ... create / delete / select / hide / reveal / mode_change ... _pre / _post).

Alexander Romanov commented

2016-06-07 16:45:13 +02:00

Changed status to: 'Open'

Alexander Romanov self-assigned this 2016-06-07 16:45:13 +02:00

Campbell Barton commented

2016-06-15 17:17:08 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2016-06-15 17:17:08 +02:00

@AlexanderRomanov, could you describe some use cases for this feature?

What you've described in your description is a bit vague and doesn't help so much in finding a general solution.

For example - if you need to set a tree as default after adding, could this be added as an option into Blender? (or is this a setting you maintain).

Regarding having callbacks on each operator (as with the patch, but filter by operator identifier).

If we add this kind of feature, its going to be used (and abused) for all sorts of cases.
So I like to see 4-6 examples where this feature is a good solution to some problem, not just some hack which allows to insert Python-calls into any tools to solve some corner cases.

@AlexanderRomanov, could you describe some use cases for this feature? What you've described in your description is a bit vague and doesn't help so much in finding a general solution. For example - if you need to set a tree as default after adding, could this be added as an option into Blender? (or is this a setting you maintain). Regarding having callbacks on each operator (as with the patch, but filter by operator identifier). If we add this kind of feature, its going to be used (and abused) for all sorts of cases. So I like to see 4-6 examples where this feature is a good solution to some problem, not just some hack which allows to insert Python-calls into any tools to solve some corner cases.

Alexander Romanov commented

2016-06-29 12:04:17 +02:00

In #48601#378264, @ideasman42 wrote:
@AlexanderRomanov, could you describe some use cases for this feature?

What you've described in your description is a bit vague and doesn't help so much in finding a general solution.

Actually I think that this is a general solution. Because you can handle any event.

For example - if you need to set a tree as default after adding, could this be added as an option into Blender? (or is this a setting you maintain).

For custom node trees, actually it is preferred to have generalized UI for linking it to any datablock (Linking Custom Node Tree to DataBlock ).
Partially this issue could be solved with D113, and I'm working on this patch now.

Regarding having callbacks on each operator (as with the patch, but filter by operator identifier).

We can agree on a set of useful operators and hardcode them. But this will be a strict limit on generalization

If we add this kind of feature, its going to be used (and abused) for all sorts of cases.

My point:
"Make another handler system for operators only (where callbacks are stored in the list inside the concrete operator type)"
So callbacks will be invoked only for specific operators. This is better for performance.

So I like to see 4-6 examples where this feature is a good solution to some problem, not just some hack which allows to insert Python-calls into any tools to solve some corner cases.

I find it difficult to show so many examples. And yes, all this cases are corner cases.

> In #48601#378264, @ideasman42 wrote: > @AlexanderRomanov, could you describe some use cases for this feature? > > What you've described in your description is a bit vague and doesn't help so much in finding a general solution. Actually I think that this is a general solution. Because you can handle any event. > > For example - if you need to set a tree as default after adding, could this be added as an option into Blender? (or is this a setting you maintain). > For custom node trees, actually it is preferred to have generalized UI for linking it to any datablock ([Linking Custom Node Tree to DataBlock ](https://wiki.blender.org/index.php/Linking_Custom_Node_Tree_to_DataBlock)). Partially this issue could be solved with [D113](https://archive.blender.org/developer/D113), and I'm working on this patch now. > Regarding having callbacks on each operator (as with the patch, but filter by operator identifier). We can agree on a set of useful operators and hardcode them. But this will be a strict limit on generalization > > If we add this kind of feature, its going to be used (and abused) for all sorts of cases. My point: "Make another handler system for operators only (where callbacks are stored in the list inside the concrete operator type)" So callbacks will be invoked only for specific operators. This is better for performance. > So I like to see 4-6 examples where this feature is a good solution to some problem, not just some hack which allows to insert Python-calls into any tools to solve some corner cases. I find it difficult to show so many examples. And yes, all this cases are corner cases.

Brecht Van Lommel commented

2016-08-05 03:18:54 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2016-08-05 03:18:54 +02:00

I don't have clear ideas on how to solve this, but since this came up in D2137 I'll give my opinion. I'm not sure if it will help you right now since it's a complicated topic..

There two systems for detecting changes in Blender:

For datablock creation, deletion or modification we have the is_updated depsgraph mechanism with associated handlers.
For datablock selection, hiding and mode changes, and for any UI changes we have the notifier system. This system is not available to addons. It gives more detailed information about what changed, but is inconsistent and incomplete.

In general, it's difficult to exactly describe a change. You might want to find out when a datablock is added. But should that be triggered on copying, on replacement, on appending, on joining, ..? It depends what you need to do exactly.

When the addon should act is also tricky. Right after the datablock is added or before it is deleted while the operator is still running seems very fragile and potentially a big performance problem. After the operators has finished running seems like the more reliable, but at that point it is difficult to precisely describe how the datablock was modified, or it might have already been deleted, copied, etc.

This is very rough, but imagine we remove the notifier system.

Depsgraph and DAG_id_tag_update could get extra flags:
Datablock "UI state" changed (selection/hiding/mode). Datablock was newly added.
** Maybe a few more, but keep it as limited as possible.
Addons would be able to handle such changes through existing hooks for detecting updates, or new hooks limited to a specific type of datablock or update flag.
Editors and UI panels should detect datablock changes from the same depsgraph flags. The notifier system is currently more fine grained, but I have some doubts about this actually helping much in practice, as we keep adding more and more notifiers to fix redraw issues.
Screens and spaces should be tagged directly to be updated, rather than going through notifiers.

I don't have clear ideas on how to solve this, but since this came up in [D2137](https://archive.blender.org/developer/D2137) I'll give my opinion. I'm not sure if it will help you right now since it's a complicated topic.. There two systems for detecting changes in Blender: * For datablock creation, deletion or modification we have the [is_updated ](https://wiki.blender.org/index.php/Dev:Source/Render/UpdateAPI) depsgraph mechanism with associated handlers. * For datablock selection, hiding and mode changes, and for any UI changes we have the notifier system. This system is not available to addons. It gives more detailed information about what changed, but is inconsistent and incomplete. In general, it's difficult to exactly describe a change. You might want to find out when a datablock is added. But should that be triggered on copying, on replacement, on appending, on joining, ..? It depends what you need to do exactly. When the addon should act is also tricky. Right after the datablock is added or before it is deleted while the operator is still running seems very fragile and potentially a big performance problem. After the operators has finished running seems like the more reliable, but at that point it is difficult to precisely describe how the datablock was modified, or it might have already been deleted, copied, etc. This is very rough, but imagine we remove the notifier system. * Depsgraph and `DAG_id_tag_update` could get extra flags: **Datablock "UI state" changed (selection/hiding/mode).** Datablock was newly added. ** Maybe a few more, but keep it as limited as possible. * Addons would be able to handle such changes through existing hooks for detecting updates, or new hooks limited to a specific type of datablock or update flag. * Editors and UI panels should detect datablock changes from the same depsgraph flags. The notifier system is currently more fine grained, but I have some doubts about this actually helping much in practice, as we keep adding more and more notifiers to fix redraw issues. * Screens and spaces should be tagged directly to be updated, rather than going through notifiers.

Chris Kohl commented

2021-05-29 06:05:40 +02:00

Added subscriber: @ckohl_art

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Extending python handlers #48601