@Dalai Felinto (dfelinto) I understand your concerns. However, I think that python developers who are able to develop their a pynodes system, that will be used by more than just a few people, are able to use this wisely themselves.
Furthermore, node systems are used to archieve flexibility (in many areas, not just animation/materials/compositing/...), I don't see why the node editor itself should not be flexible just because Blender does not need this.

I was wondering, how are the types selected that require __MT__, ... in the bl_idname? Because atm this convention only exists for some types, right? Most of the types you mention in your initial post don't require this (yet), correct?

I'm not against naming conventions. However I'm against knowledge duplication in code. Eg: when I already say that a specific class is a Panel, then I don't need to put that information into the identifier.

While writing the proposal I considered supporting:

mt = bpy.types.Menu.find("SOME_MT_menu")

The main reason against this is it would break a lot of scripts, (anything that touches the file-menu - so import/exporters).

For 2.8x perhaps this is OK, I'd rather avoid large breakages for minimal gains.

Here are a few ideas that I have on the topic:

Here is why Animation Nodes would benefit from this patch:

Just tried the approach with the custom property on the mesh. It did not seem to work.

I see, thanks for the clarification.

I created the new issue: https://developer.blender.org/T51311

Hey, I just started enjoying alembic export and import. It's really cool to cache some output of Animation Nodes.
I wanted to ask is this: Is possible to export (animated) curve objects (converted to a mesh possibly)?

Thanks for the report. I fixed it: rBS7a63d81bfa0f253dfb8a79875adf11506289ad8b
The problem was the shape attribute of the buffer.

Hey again, just wanted to know if there is anything I can do to help to merge this into master before the next release.

I implemented the requested changes in the id_props branch in the Blender Staging repository: https://developer.blender.org/diffusion/BS/browse/id_props/

@Julian Eisel (Severin) does using a uint64_t bitfield mean that there cannot be more than 64 different socket types? I don't think that a limitation in the amount of socket types would be good. This might be enouph for material and other specialised node tree types. However that is not enouph for generic node tree types as Animation Nodes. I just counted, I already implemented 60 different types. And there will be more eventually, also because some other developers implement their own types for their specific needs.

I wonder how many operators actually use this property?
I mean it would be easy to store the previous mouse position in the operator itself, there is no need for this to be in the Event.

Please update to Blender 2.77 if you want to use Animation Nodes 1.5

Ah thank you for the info.

Can you try to use the scene simplification to disable the subsurf modifiers in the viewport?
That seems to solve the problem on my pc..

Oh and now I'm getting another error:

This is the traceback I get from gdb. (note: this is my first attempt to debug blender)

yes. maybe my code leaves the mesh in an invalid state or so. I don't know why that happens sometimes and sometimes not but thats another thing.
At least it would be helpful if you could also try to simplify your file.

Maybe ist also a bug in my addon, because when I remove all nodes it does not crash. I will try to simplify the file later today.

Yes okay. I just found a work around for me.
All nodes in my Addon are subclasses of bpy.types.Node and AnimationNode. When I make bl_width_max = 5000 as class property of the AnimationNode class then all other nodes uses that max value.
But yes. I guess 1000 is definitly enouph.
Thanks! :)

Yes the render_pre and render_post events are called.
Is there a reliable way to check wether the scene_update functions are triggered while rendering or not?

Increasing the 320 to some higher number would be ok for me but I wonder for what this property is needed and why it has to be such a 'low' value. Happens something bad when the width is 10.000 or so? Not that I need such a wide node, but why is there this limitation?

Ahh I see that makes sense! But why frame_change_post event also not called?
I mean there is definitly a frame change. And when I have a script that changes the text in a text effect sequence based on the frame I would need some kind of callback here..
Personally I would prefer to have the scene_update event called here as well but I understand why it is not the case currently...

I just tested it on Ubuntu 15.10 64 bit. Same problem here.

Ah sorry. Here the file. Just open it and try to make the node larger or smaller.

Not sure if this is directly related to this commit, but somehow reloading the Animation Nodes addon by pressing F8 doesn't work in the latest build bot version anymore.

This happens also after I set back to factory Settings if you mean that?