Upgrading Blender add-ons from 2.79 to 2.80, part 4

glLineStipple and co are gone, must be replaced by shaders

This popped when working with the bgl module. There is a good shader based alternative however with an example in the docs.

Groups are now collections

which means references to bpy.data.group must be replaced by bpy.data.collection

Setting active object is different

You assign an object to bpy.context.view_layer.objects.active.
In many circumstances the view_layer is now the ultimate arbiter of what we see. This allows for organizing the visibility of objects in a scene but it also offers the link to the active object.

You must use ob.select_set(<bool>) instead of ob.select = <bool>

This is a breaking change change that could have been avoided: if it was necessary to move from a simple assignment to executing some code when the select status changes it would have been possible to use a property instead. Now it is just an annoying change in my opinion

The name of module may not contain a point either

See item on dash being not allowed in an earlier article

INFO_MT_mesh_add menu is now called VIEW3D_MT_mesh_add

Which makes sense because it is part of the VIEW3D area.

use_subsurf_uv no longer available on a subsurf modifier

Too bad, but I guess this wasn used very often anf the new quality settings of the modifier might well server the purpose even better.

no bl_category in Panels

So you cannot decide where your Panel will be located in the Toolbar.

That's what I thought earlier and it is true but only if your region type is TOOLS (visible with Ctrl-T) but you can still have a category if your region type is UI (visible with Ctrl-N)

Upgrading Blender add-ons from 2.79 to 2.80, part 3

While porting my add-ons from Blender 2.79 to 2.80 I encounter all sorts of compatibility issues that I report on from time to time in this blog. Some of those of issues are minor but others go deeper and might take quite some effort to fix.

In previous articles I listed a fair number of issues (1, 2) but the good news is that the number of new issues that pop up is diminishing. Last week's batch is rather small:

• context.user_preferences becomes context.preferences. That is fairly easy to fix but unfortunately this could break stored preferences as well since they might contain references to this attribute in the set itself (A stored preference or preset is executable Python code that basically sets all sorts of variables)

• BVHTree.fromobject and related functionality was broken but is now fixed. Thanks to very rapid follow up by Blender dev Bastien Montagne! Note that even though the bug is fixed, the signature of this function (and related ones) has changed: It no longer takes a Scene argument but a Depsgraph argument.

• context.area.header_text_set(None) must be used instead of context.area.header_text_set("") to restore the default menu. This is not a big thing but if you forget you get an empty taskbar.

Upgrading Blender add-ons from 2.79 to 2.80, part 2

In the first part of this series on porting add-ons from 2.79 to 2.80 I promised to keep notes on issues that might pop-up so here is my second batch:

• scene.objects.active is no longer available. Use context.active_object. This is due to working with collections,
• no bl_category, so you cannot decide where your Panel will be located in the Toolbar. This is too bad, but maybe I don understand this completely,
• the bgl module does not support direct mode at all (not even as an option). This hurts really bad. Yes the new , modern OpenGL capabilities are what we all wished for but porting the old stuff to the new is far from trivial,
• BVHTree.FromObject() expects a Depsgraph not a scene. This is a breaking change. The relevant Depsgraph is available from context.depsgraph,
• scene.ray_cast() expects a view_layer to determine what is visible in the scene. Again a breaking change related to the previous one. The relevant view_layer is available from context.window.view_layer,
• Lamps are now called Lights, this affects object.type ('LIGHT') as well as bpy.data.lights,
• Color() constructor always expects 3 values, but the .color attribute in a vertex color layer is 4 items (RGBA). Like the next item on this list this might have been present in 2.79 already but just comes to light now that I am porting add-ons,
• The name of a module may not contain -  (i.e. a dash or minus sign) or install will silently fail (might have been the case in 2.79 too)

Upgrading Blender add-ons from 2.79 to 2.80

i have started research into upgrading my (commercial) add-ons from 2.79 to 2.80. in documenting what i encounter, i hope i can spare people some frustrations and learn something about add-ons in general. i didn't start earlier, partly because i had some other stuff to do but mainly because the Python API needed to be finalized and more or less stable: with many add-ons to consider for an upgrade starting when everything is still in flux would run the risk of wasting a lot of time.

Expectations

the Blender developers provided some documentation in the API changes in in a short document. Unfortunately, quite a few of them are breaking changes, i.e. the have to be changed in order to work at all. Many of these changes impact every add-on, like no longer having a register_module() utility function while some others apply mainly to math heavy add-ons, like the use of the @ operator for matrix multiplication. Unfortunately quite a few of my add-ons are math heavy so i will probably need to spend quite some time on this.

Annoyances

the Blender devs decided it was a good idea to force all keyword parameters to actually use those keywords. And indeed this will prevent accidentally using a positional argument as a keyword argument and aid in readability. This is a Good Thing™. However it is bloody annoying that layout.label() is affected by this, which I use a lot which just a single text argument ...
The price for biggest annoyance however goes to the mandatory change that forces class variables that are initialized with a call to some sort of property function like an Operator with for example a size = FloatProperty(name="size") property, to a type annotation like size: FloatProperty(name="size")
A small change it may seem but properties are everywhere so it is a lot of work. And although i read the PEP thoroughly, I fail to see the advantage. I'd rather hoped the devs would concentrate on things that change because of Blender's new structure, like collections and viewport related things, than on this new Python fad ...

Upcoming

I am just starting the research on converting my add-ons but you can expect a couple of articles the next couple of months with hopefully some useful findings.