Add Handlers to Operators. #86191

New Issue

Jaume Bellet · 2021-03-02T13:45:07+01:00

Jaume Bellet commented

2021-03-02 13:45:07 +01:00

Motivation

I have found a needed to do something from python, when an operator is being executed.

Usage examples

an add-on is doing managing with geometry and needs to perform something when vertices are deleted.
an add-on could use translate operator to move something it controls, related to vertices positions.

Example code can be found on D10579

Design

See M2

Development steps

{icon check-square-o color=green} execute pre and post funtions on invoke
{icon check-square-o color=green} allow handlers removal
{icon check-square-o color=green} get the operator return code on py func
{icon check-square-o color=green} get the operator parameters on py func
{icon check-square-o color=green} loop only for operator self handlers
{icon check-square-o color=green} add modal handler
{icon check-square-o color=green} poll function
{icon check-square-o color=green} modal_end handler
{icon check-square-o color=green} context and event available on all handlers and poll function
{icon check-square-o color=green} delete all modal handlers from one owner in a single call

Know Issues

Feedback is welcome!

## Motivation I have found a needed to do something from python, when an operator is being executed. ## Usage examples * an add-on is doing managing with geometry and needs to perform something when vertices are deleted. * an add-on could use translate operator to move something it controls, related to vertices positions. Example code can be found on [D10579](https://archive.blender.org/developer/D10579) ## Design See M2 ## Development steps * {icon check-square-o color=green} execute pre and post funtions on invoke * {icon check-square-o color=green} allow handlers removal * {icon check-square-o color=green} get the operator return code on py func * {icon check-square-o color=green} get the operator parameters on py func * {icon check-square-o color=green} loop only for operator self handlers * {icon check-square-o color=green} add modal handler * {icon check-square-o color=green} poll function * {icon check-square-o color=green} modal_end handler * {icon check-square-o color=green} context and event available on all handlers and poll function * {icon check-square-o color=green} delete all modal handlers from one owner in a single call ## Know Issues Feedback is welcome!

Jaume Bellet self-assigned this 2021-03-02 13:45:07 +01:00

Jaume Bellet commented

2021-03-02 13:45:07 +01:00

Added subscribers: @JaumeBellet, @ideasman42

Robert Guetzkow commented

2021-03-02 13:47:00 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2021-03-02 13:47:00 +01:00

Changed status from 'Needs Triage' to: 'Archived'

Robert Guetzkow closed this issue

2021-03-02 13:47:00 +01:00

Robert Guetzkow commented

2021-03-02 13:47:01 +01:00

Thank you for your report. Improvement suggestions and feature requests are off-topic on the bug tracker. Proposals can be posted on right-click select.

Thank you for your report. Improvement suggestions and feature requests are off-topic on the bug tracker. Proposals can be posted on [right-click select. ](https://blender.community/c/rightclickselect/)

Jaume Bellet commented

2021-03-02 14:02:09 +01:00

Removed subscriber: @ideasman42

Jaume Bellet commented

2021-03-02 14:02:09 +01:00

i thought a task should be created first, just starting to implement it.

Created the diff

https://developer.blender.org/D10579

thanks!

i thought a task should be created first, just starting to implement it. Created the diff https://developer.blender.org/D10579 thanks!

Robert Guetzkow commented

2021-03-02 14:25:27 +01:00

Changed status from 'Archived' to: 'Needs Triage'

Robert Guetzkow reopened this issue

2021-03-02 14:25:27 +01:00

Robert Guetzkow commented

2021-03-02 14:25:27 +01:00

I see, the ticket didn't seem like you intended to implement this yourself.

Robert Guetzkow commented

2021-03-02 20:30:02 +01:00

Has this been discussed on DevTalk before and approved by one of the Python API module members?

Ryan Inch commented

2021-03-03 04:28:31 +01:00

Added subscriber: @Imaginer

Jaume Bellet commented

2021-03-03 07:07:03 +01:00

In #86191#1122822, @rjg wrote:
Has this been discussed on DevTalk before and approved by one of the Python API module members?

No, it's a needed i found while trying to port what was done in the past in a fork (mechanical blender) to an addon.

> In #86191#1122822, @rjg wrote: > Has this been discussed on DevTalk before and approved by one of the Python API module members? No, it's a needed i found while trying to port what was done in the past in a fork (mechanical blender) to an addon.

Jaume Bellet commented

2021-03-03 19:03:55 +01:00

I've upload a Diff for tests. It still needs work, but would be great is some advice could be given before continuing.

Thanks!

I've upload a Diff for tests. It still needs work, but would be great is some advice could be given before continuing. Thanks!

Jaume Bellet commented

2021-03-04 07:43:33 +01:00

Seen https://developer.blender.org/D2052

the approach proposed here is less invasive

Seen https://developer.blender.org/D2052 the approach proposed here is less invasive

Demeter Dzadik commented

2021-03-04 11:29:24 +01:00

Added subscriber: @Mets

Demeter Dzadik commented

2021-03-04 11:29:24 +01:00

Some rigging use cases:

Add more "hacky" behaviour to the armature Symmetrize operator. (post-execute)
Entering weight paint mode would put the relevant armature and shading settings in the correct state automatically. (pre-execute)
Extruding a bone whose name already ends with a number would increment the number instead of adding .001. (post-execute)
Run newly added text datablocks with Register enabled on Append/Link.

Do you think these would already be possible to implement? If so, I might give it a try using your patch. Just let me know when you'd need some testing (And maybe give some more examples of the new python API calls that are possible with the patch).

I also think it would be nice to have this behave more like the current app handlers:

Adding a handler means appending it to a list. This is nice because it allows multiple addons to add functionality to an existing operator.
The name of the handler makes it abundantly clear when the code runs, eg. "frame_change_pre" runs before a frame change, and that's completely clear even when the name is in a vacuum. With a name like "handlers.invoke" it's unclear whether it runs before or after the operator's invoke function.

For example, I would expect
bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)
my_func() would be called before the operator's invoke()
Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc.
What do you think about this?

Some rigging use cases: - Add more "hacky" behaviour to the armature Symmetrize operator. (post-execute) - Entering weight paint mode would put the relevant armature and shading settings in the correct state automatically. (pre-execute) - Extruding a bone whose name already ends with a number would increment the number instead of adding .001. (post-execute) - Run newly added text datablocks with Register enabled on Append/Link. Do you think these would already be possible to implement? If so, I might give it a try using your patch. Just let me know when you'd need some testing (And maybe give some more examples of the new python API calls that are possible with the patch). I also think it would be nice to have this behave more like the current app handlers: - Adding a handler means appending it to a list. This is nice because it allows multiple addons to add functionality to an existing operator. - The name of the handler makes it abundantly clear when the code runs, eg. "frame_change_pre" runs before a frame change, and that's completely clear even when the name is in a vacuum. With a name like "handlers.invoke" it's unclear whether it runs before or after the operator's invoke function. For example, I would expect `bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)` my_func() would be called before the operator's invoke() Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc. What do you think about this?

Jaume Bellet commented

2021-03-04 12:26:51 +01:00

In #86191#1123946, @Mets wrote:
For example, I would expect
bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)
my_func() would be called before the operator's invoke()
Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc.
What do you think about this?

In current Diff the handler is set as

bpy.ops.mesh.primitive_cube_add.handlers.invoke(owner,invoke_callback,(1,))

And is adding the callback on a list, so an operator can have multiple handlers. I added the owner because will be used for unregistering in a block (not already done).

Completely agree that your notation is better so i'll change it.

Thanks!

> In #86191#1123946, @Mets wrote: > For example, I would expect > `bpy.ops.mesh.primitive_cube_add.handlers.invoke_pre.append(my_func)` > my_func() would be called before the operator's invoke() > Similarly, invoke_post, draw_pre, draw_post, execute_pre, execute_post, etc, etc. > What do you think about this? In current Diff the handler is set as ``` bpy.ops.mesh.primitive_cube_add.handlers.invoke(owner,invoke_callback,(1,)) ``` And is adding the callback on a list, so an operator can have multiple handlers. I added the owner because will be used for unregistering in a block (not already done). Completely agree that your notation is better so i'll change it. Thanks!

Jaume Bellet commented

2021-03-04 14:09:02 +01:00

Uploaded a build for testing.

Graphicall Windows debug build

Uploaded a build for testing. [Graphicall Windows debug build ](https://blender.community/c/graphicall/vsbbbc/)

Demeter Dzadik commented

2021-03-05 11:31:01 +01:00

Added subscriber: @ideasman42

Demeter Dzadik commented

2021-03-05 11:31:01 +01:00

Before you burn too much time into this, it might also be good to have some devs from the PyAPI module take a look at the idea to make sure they're okay with it. @ideasman42 perhaps?

Jaume Bellet commented

2021-03-05 12:32:56 +01:00

@Mets Sure, thanks for your advice ;)

At this point until no response, I'll move onto an approximation for #86264 and later I'll continue my work on mechanicalblender add-on.

Have a nice weekend!

@Mets Sure, thanks for your advice ;) At this point until no response, I'll move onto an approximation for #86264 and later I'll continue my work on mechanicalblender add-on. Have a nice weekend!

Travis commented

2021-03-06 19:42:49 +01:00

Added subscriber: @TravisOBrien

Wilsimar commented

2021-03-07 15:07:37 +01:00

Added subscriber: @wilBr

Wilsimar commented

2021-03-07 15:23:25 +01:00

@JaumeBellet this is a much have enhancement... thank you

another use cases....

. addon for viewport undo/redo view matrix changes

. with modal handler, unlock view navigation for standard transform tools/operators

. display warning while entering in edit mode (tab key) if object is procedurally builded or display window settings for adjust it rather than entry in edit mode

@JaumeBellet this is a much have enhancement... thank you another use cases.... . addon for viewport undo/redo view matrix changes . with modal handler, unlock view navigation for standard transform tools/operators . display warning while entering in edit mode (tab key) if object is procedurally builded or display window settings for adjust it rather than entry in edit mode

eldee smith commented

2021-03-07 18:49:00 +01:00

Added subscriber: @testure

Campbell Barton commented

2021-03-08 07:09:20 +01:00

Personally I'd put this functionality on hold (IIRC this been proposed and rejected before).

It's allows for some odd situations.

functions may change the state so the operators poll function doesn't succeed anymore.

Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected.

'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through.

There are more general down-sides to wrapping operators too.

For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list.
In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator.

The same goes for mode switching. In that case it's possible to register a callback to the object mode using bpy.msgbus.

We could make sure notifications that Python developers find useful (such as selection) properly publish changes to bpy.msgbus, then script authors could use this as a reliable way to respond to selection changes.

There will still likely be some use-cases that can't be handled in a generic way.

This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this.

So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

Personally I'd put this functionality on hold (IIRC this been proposed and rejected before). It's allows for some odd situations. - functions may change the state so the operators poll function doesn't succeed anymore. ``` Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected. ``` - 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through. ---- There are more general down-sides to wrapping operators too. For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list. In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator. The same goes for mode switching. In that case it's possible to register a callback to the object mode using `bpy.msgbus`. We could make sure notifications that Python developers find useful (such as selection) properly publish changes to `bpy.msgbus`, then script authors could use this as a reliable way to respond to selection changes. ---- There will still likely be some use-cases that can't be handled in a generic way. This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this. So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

Jaume Bellet commented

2021-03-08 08:14:04 +01:00

Thanks for your comments!

In #86191#1125789, @ideasman42 wrote:
Personally I'd put this functionality on hold (IIRC this been proposed and rejected before).

It's allows for some odd situations.

functions may change the state so the operators poll function doesn't succeed anymore.

Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected.

'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through.

The pre-invoke callback, could be moved before operator poll call, and also a callkback to get the poll result could be set, so developer could be aware of it. The past-through can be handled in post function, as is getting as operator result.

In #86191#1125789, @ideasman42 wrote:

There are more general down-sides to wrapping operators too.

For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list.
In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator.

The same goes for mode switching. In that case it's possible to register a callback to the object mode using bpy.msgbus.

We could make sure notifications that Python developers find useful (such as selection) properly publish changes to bpy.msgbus, then script authors could use this as a reliable way to respond to selection changes.

Of course bpy.msgbus is better handling needs that affects in general way, but for specific does not. In my case I'm looking for a way of selecting python scope objects in a seamless way, and also i would use to create default extra data depending on data created (eg, in my case could be default dimensions in a cube)

In #86191#1125789, @ideasman42 wrote:
There will still likely be some use-cases that can't be handled in a generic way.

This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this.

So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

by dangerous, do you refer "unexpected" ? I obviously can agree here, but allowing making thinks more seamless and automatized (without workarounds) worth in terms of add-ons quality and user performance.

Thanks for your comments! > In #86191#1125789, @ideasman42 wrote: > Personally I'd put this functionality on hold (IIRC this been proposed and rejected before). > > It's allows for some odd situations. > > - functions may change the state so the operators poll function doesn't succeed anymore. > > Even if this is accounted for with an extra check, it could result in scripts ending up in a poorly defined state where pre/post functions don't behave as expected. > > - 'pre' functions would run, even if the operator doesn't, as some operators check for spesific situations and return pass-through. > > ---- The pre-invoke callback, could be moved before operator poll call, and also a callkback to get the poll result could be set, so developer could be aware of it. The past-through can be handled in post function, as is getting as operator result. > In #86191#1125789, @ideasman42 wrote: > > There are more general down-sides to wrapping operators too. > > For example, script authors that want to respond to changes to selection, are likely to seek out all operators that change selection, then add handlers to all of them. This isn't good design since operators from add-ons might change selection which won't be included in this list. > In that case we would be better off to be able to know when the selection changed, instead of adding callbacks to every selection operator. > > The same goes for mode switching. In that case it's possible to register a callback to the object mode using `bpy.msgbus`. > > We could make sure notifications that Python developers find useful (such as selection) properly publish changes to `bpy.msgbus`, then script authors could use this as a reliable way to respond to selection changes. > > ---- Of course bpy.msgbus is better handling needs that affects in general way, but for specific does not. In my case I'm looking for a way of selecting python scope objects in a seamless way, and also i would use to create default extra data depending on data created (eg, in my case could be default dimensions in a cube) > In #86191#1125789, @ideasman42 wrote: > There will still likely be some use-cases that can't be handled in a generic way. > > This gets into a question of allowing script authors to do dangerous things. From a maintainers perspective this often doesn't seem worthwhile since we will here form users who run into bugs caused by features like this. > > So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. by dangerous, do you refer "unexpected" ? I obviously can agree here, but allowing making thinks more seamless and automatized (without workarounds) worth in terms of add-ons quality and user performance.

eldee smith commented

2021-03-08 20:45:00 +01:00

In #86191#1125789, @ideasman42 wrote:
So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. I can't subscribe to object.data and get a callback when mesh data changed for a specific object because the user ran a bevel operation or whatever. Talking about script authors doing dangerous things- it's already happening because we're trying to work around bpy's lack of a proper event/subscriber system. Technical artists around the world are abusing modal operators and timers to get the results they need (which is usually notification that an event has happened, an operator has been triggered, etc)

> In #86191#1125789, @ideasman42 wrote: > So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. I can't subscribe to object.data and get a callback when mesh data changed for a specific object because the user ran a bevel operation or whatever. Talking about script authors doing dangerous things- it's already happening because we're trying to work around bpy's lack of a proper event/subscriber system. Technical artists around the world are abusing modal operators and timers to get the results they need (which is usually notification that an event has happened, an operator has been triggered, etc)

Campbell Barton commented

2021-03-09 04:52:24 +01:00

@testure

In #86191#1126432, @testure wrote:

In #86191#1125789, @ideasman42 wrote:
So personally I'd rather make sure bpy.msgbus is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for.

It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA.

Support for this should be added, while not exactly a bug, it should be possible to reliably subscribe to these kinds of events.

@testure > In #86191#1126432, @testure wrote: >> In #86191#1125789, @ideasman42 wrote: >> So personally I'd rather make sure `bpy.msgbus` is a reliable way to respond to changes to Blender data, which I think covers many of the cases this kind of feature would end up being used for. > > It could be that I have just not found the correct use-case for msgbus, but from my own experiences I have never been able to use it for what I need it for. For example- if i want to subscribe to object.location, my callback doesn't fire if the user moved the object in the viewport because it doesn't go through RNA. Support for this should be added, while not exactly a bug, it should be possible to reliably subscribe to these kinds of events.

Wilsimar commented

2021-03-10 19:02:58 +01:00

added modal handlers.. great...

Can you do a, no debug, compiled blender version? I can't to run last graphicall version cause so many microsoft's debug DLL missing. (msvcp140d.dll, ucrtbaseD.dll, vcruntime140_1d.dll ......)

thank you.

added modal handlers.. great... Can you do a, no debug, compiled blender version? I can't to run last graphicall version cause so many microsoft's debug DLL missing. (msvcp140d.dll, ucrtbaseD.dll, vcruntime140_1d.dll ......) thank you.

Jaume Bellet commented

2021-03-11 07:39:18 +01:00

Sure!, also the uploaded one was uploded on first tests.

Jaume Bellet commented

2021-03-11 08:37:22 +01:00

updated! https://blender.community/c/graphicall/vsbbbc/

Jaume Bellet commented

2021-03-11 09:27:16 +01:00

Added subscriber: @DotBow

Jaume Bellet commented

2021-03-11 09:27:16 +01:00

In D10579 #270638, @DotBow wrote:
Hi!
Very interesting and helpful addition!
Does this mean that it will be possible to execute somethng in-between modal operators as well (i.e. detect start and finish)?
I already have some ideas where it can improve my workflow a lot! Thanks!

I reply here.

Yes, but i think in this case a modal_end callback should be added, because executing always a python callback for each modal operator loop would be unnecessary. Need to check that.

Also the return code on modal operator function should be bypassed to python callback (currently missing)

> In [D10579](https://archive.blender.org/developer/D10579)#270638, @DotBow wrote: > Hi! > Very interesting and helpful addition! > Does this mean that it will be possible to execute somethng in-between modal operators as well (i.e. detect start and finish)? > I already have some ideas where it can improve my workflow a lot! Thanks! I reply here. Yes, but i think in this case a modal_end callback should be added, because executing always a python callback for each modal operator loop would be unnecessary. Need to check that. Also the return code on modal operator function should be bypassed to python callback (currently missing)

Demeter Dzadik commented

2021-03-11 10:35:33 +01:00

Accidently posted this in the patch instead of here first, but here is more relevant:

Are you still hoping to convince the devs that this is worth adding to blender? Or are you happy to continue development even if it doesn't get into master?

Accidently posted this in the patch instead of here first, but here is more relevant: Are you still hoping to convince the devs that this is worth adding to blender? Or are you happy to continue development even if it doesn't get into master?

Jaume Bellet commented

2021-03-11 13:37:08 +01:00

I think both!

After some expectations with add-ons i've seen, I have already assumed the project I am involved with will continue being a fork, more add-on focused. and I'll use this feature. All specific things will go over Python, i'll submit tasks and patches here for things that could benefit Blender and it's users. (may be some things more focused for mechanical engineering / arch users, but this does not mean could be great for all)

I can understand the point of view of core devs, as they are responsible of the most low level functionality, this means that any change here can affect lots and every where.

Not related to blender development people, can expand blender via add-ons, and this is great, but the workarounds (modals, abusive timers, compute things in drawing callbacks, etc) they are definitively not. (What happens with large scenes? or if you have a lot of addons on background?) And also the UI part of most addons is not "natural". This goes against user productivity. Would it be great if before selecting i must always think before what i want to select (face? vertex? edge?) ,select the specified tool and do the selection?

I Remember Ton said once time ago that if you consider something should be added, you should make noise, and explain your proposal to the world. If this development was stopped at first "put on hold proposal", others could not see the possible potential and benefits (or issues), so they could support it if they like and as a group, achieve to get it included on official releases, with the needed changes to meet blender quality, of course.

I think both! After some expectations with add-ons i've seen, I have already assumed the project I am involved with will continue being a fork, more add-on focused. and I'll use this feature. All specific things will go over Python, i'll submit tasks and patches here for things that could benefit Blender and it's users. (may be some things more focused for mechanical engineering / arch users, but this does not mean could be great for all) I can understand the point of view of core devs, as they are responsible of the most low level functionality, this means that any change here can affect lots and every where. Not related to blender development people, can expand blender via add-ons, and this is great, but the workarounds (modals, abusive timers, compute things in drawing callbacks, etc) they are definitively not. (What happens with large scenes? or if you have a lot of addons on background?) And also the UI part of most addons is not "natural". This goes against user productivity. Would it be great if before selecting i must *always* think before what i want to select (face? vertex? edge?) ,select the specified tool and do the selection? I Remember Ton said once time ago that if you consider something should be added, you should make noise, and explain your proposal to the world. If this development was stopped at first "put on hold proposal", others could not see the possible potential and benefits (or issues), so they could support it if they like and as a group, achieve to get it included on official releases, with the needed changes to meet blender quality, of course.

Demeter Dzadik commented

2021-03-11 15:04:37 +01:00

Well, I really like your attitude, and am excited to see where this goes! :D

Jaume Bellet commented

2021-03-12 14:40:05 +01:00

Things are clear with a flow diagram ;) Need to change diff to match it

Jose Conseco commented

2021-03-16 20:30:41 +01:00

Added subscriber: @JoseConseco

Lucky Kadam commented

2021-03-22 13:07:41 +01:00

Added subscriber: @kadam

Cristian Moga commented

2021-03-22 16:50:09 +01:00

Added subscriber: @in10siv

Jaume Bellet commented

2021-03-29 13:52:12 +02:00

D10852 allows to add data to existing enums, so it can be used to add new functionality on operators based on this new value checking the value on the handler for the operator.

[D10852](https://archive.blender.org/developer/D10852) allows to add data to existing enums, so it can be used to add new functionality on operators based on this new value checking the value on the handler for the operator.

Chris Kohl commented

2021-05-29 05:56:23 +02:00

Added subscriber: @ckohl_art

Raimund Klink commented

2022-07-18 12:11:52 +02:00

Added subscriber: @Raimund58

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add Handlers to Operators. #86191

Motivation

Usage examples

Design

Development steps

Know Issues