@Alexander Romanov (a.romanov), 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.

In T48601#378264, @Campbell Barton (campbellbarton) wrote:

@Alexander Romanov (a.romanov), 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.

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.