You misundertood. I'm doing that already, see blend file or video demo. But it won't cause the PreferencesInput.use_auto_perspective to work, in that it won't return to a perspective view once the user rotates the view.

@Campbell Barton (campbellbarton) With the mentioned change, Is there any way now, to set a custom orthographic view (not side view) via Python, but have it then also respect the PreferencesInput.use_auto_perspective setting, and so return to a perspective view, once the user rotates the viewport?

This doesn't seem to be related to my addons in any way. But I'd encourage Nick to try Akhil's solution.

Yes, I only run it once in __init__.py in register()

Maybe that's a bug.

It seems like that to me.

I did. I noticed, that when the Interface Preferences are set to "Keep Existing", which seems to be the new default, it will remember its position. But if it's set to "Bottom", it will always return to top again.

Understood, thank you. Much appreciated! Feel free to close.

That's pretty inconvenient though, especially since it used for work perfectly in the past. What would you recommend? Keeping track of the vgroup names and use that to fetch them?

Closing, as I've realized I can just do the G.moving check (or something similar) myself.
In fact you can check if any of the group's gizmos is_modal prop is True to determine how to draw (or hide gizmos) in draw_prepare() while the operator runs.

Fantastic, thanks for the info. Again, very much appreciated!

Thank you, I appreciate that.

You didn't get an exception on Windows? It get's more interesting by the minute.

This is the result on Windows

I think I should clarify some more.

When you said pool instead of poll, it sounded like the introduction of it is the cause for this.
If the poll checking for G.moving is not new, than why did the behavior change in 3.0?

@Germano Cavalcante (mano-wii) There are other - probably related behaviour - changes too. For instance I can't even manually adjust gizmo.use_modal_draw in a modal op, which worked perfectly before, but doesn't anymore. I assumed it is related to this issue here.

I think this one is for you again @Campbell Barton (campbellbarton)
Thank you!

Ì'd appreciate it if you could take a look at this @Campbell Barton (campbellbarton). Thank you!

We could overlap both, although it feels a bit crowded to have 2x rows of buttons floating at the top of the 3D viewport.

I understand that. But I tend to work without the Tool Settings. So 2 rows of floating buttons are no concern to me.

This appears to be resolved, yay! Closing.

Do you want to take a look at this @Pablo Vazquez (pablovazquez)?

Thanks for finding that commit!

Thanks for investigating!

Just wanted to bump this, as I feel it's a major shortcoming of the bevel tool/mod right now. I hope this will be resolved in 3.0, but would prefer it much earlier.

I'm closing this as nobody is assigned to it anyway, and as far as I can see it's not an issue in 2.93 anymore.

FWIW, scene.ray_cast does not have these issues either.

Returning the final index is what I would expect yes. It already does return the final distance, location and normal. For boolean mods it also already returns the final index too, hence why I was caught off guard, when getting these results for mirror(and potentially other?) mods.

that at that angle, you have to go about 4 times as much along the sliding edge as the width desired

I would be fine with that, not matter the angle. If I want to loop slide along the edges I have placed, then I want to loop slide along them. Ideally, there would be an option to do this, so use loop slide without any cut off angle.

I've added a second example, this time using the bevel mod.

@Ankit Meel (ankitm) Thanks for merging my report. I was aware of this one here, but thought a more generalized phrasing would draw more attention to, what looks like a very pressing issue.
If you think it makes sense, maybe rename this one here to reflect that?
Anyway, thanks for the fix, hope it gets committed quickly!

It does not seem to happen when setting custom normals using Blender's native tools, for instance using mesh.set_normals_from_faces()
But it will happen when doing it from python. Here's a sample implementation for setting custom normals from the active face:

Thank you!

Thanks for pointing that out, much appreciated!

@Robert Guetzkow (rjg) Just wanted to comment as well, in case this is in response to Eric, whom I've sent here. His crashes are related to adding/removing ID data using layout.template_icon_view and so changing ID data from enum update callbacks. This is still unresolved, yet my reports about it were all closed.
I was told conflicting information: 1. Don't change ID data from update callbacks and don't run operators from them, 2. If you change ID data use operators. Following this advice means the template_icon_view layout element has become useless for its most popular use case: adding external assets. Since Blender is crashing when undoing after such an operation, it also risks data loss for a huge amount of Blender users.

Read all of this, still don't have a working solution to prevent Blender crashing when appending using the layout.template_icon_view() as the interface (followed by undo)