Is this feature still relevant? The inital commit is almost 6 months old and little drive towards acceptance. So, if there are plan to integrate it, I like to update the patch. Otherwise it would be best to abandon it.

@Germano Cavalcante (mano-wii): Thanks. I have substituted the function as suggested.
@Hans Goudey (HooglyBoogly): Radius factor applies now to every bevel piece.

@Hans Goudey (HooglyBoogly): I still don't know what you mean by radius. There is a check box called radius but I can't see an effect when check marked even not on master.
Or do you mean the depth slider (which says "Radius of the bevel geometry" when hoovering over it and which seems to work just fine")?

Hmm, right now I am not sure what your expectations are. The radius seems useless to me or I am just not able to trigger it.

@Hans Goudey (HooglyBoogly) : Thx. I know but this is the consequence of the approach. Future improvements might by rounded corners or similar geometric improvements.

Hey @Roman (roman13), it might be the easiest way when you build blender yourself? Here https://wiki.blender.org/wiki/Tools/CodeReview you can find information how to apply the patch and here https://wiki.blender.org/wiki/Building_Blender how to build blender.
Unfortunately, I have no idea if and when this patch is going to be merge into master.

@Sergey Sharybin (sergey) : Thank you for your review. I tested it once again and I don't think the code is redundant. You won't be able to extrude a surface. You will one extrude if you select a single point. This behaves then like a regular curve. Please see my comment.

I reassigned the key mapping to select a row to "alt + mouse selection button". It has now a similar behavior to MESH_OT_loop_select. However, the edge selection feature is not implemented yet. That's what I will do next. You are right. This should be more or less straight forward.

reassigned keymapping

Sound like an great exercise. Any pointers to useful code I can take a peak?

@Hans Goudey (HooglyBoogly) I tried to be more clear what the code is doing and tried to implement your suggested improvements. To me it is not at all annoying, it is a great learning experience. Thank your for your great help and reviews. I hope I was able to do better now.

Btw, I just checked the manual https://docs.blender.org/manual/en/latest/modeling/surfaces/selecting.html#select-control-point-row which documents the hotkey "shift + r" as assigned to another command. Since I suggested a patch, now I am quite unsure if there is a usability conflict.

I went once more over the code and was able to simplify it further.

I have provided an Bugfix. I don't know, if the behavior described here was former intended design. If not, it is fixed now.
It can be found in D9934.

I have updated the patch in D9931. Maybe, it helps to resolve this issue.

Initially, I provided a small patch in D9509 that fixes T83831 and does not produce the bug described in this task. I just applied it again and tested it successfully. However, it was abandoned and I don't understand exactly why. In D9509 you can find a short discussion where I made a concern about zeroing the coordinates. Maybe, I was not completely wrong.

UI checkbox for angle based radius included. Please see the screenshot

In D9678#247796, @Germano Cavalcante (mano-wii) wrote:

Good to see someone working on it :)

Nice, thx. It is quite challenging for a good first issue.

Incorporated review from Hans Goudey

The blend file I have upload is take from T83207.

I have updated my fix D9678 which should no more produce distortions in the bevel. I have tested it with many files and could not identify any issue. It even fixes the issues with the distortion in the attached file (I am not sure in which issue I found this file)

• Thorough fix of bevel distortion

Fixes bevel distortion in xy plane.
I gave it some work, but did not manage to fix it when there is beveling in the z direction.
I tried to handle everything with an angle based approach. Right now, I do not know what exactly causes the problems in z direction.

Thank you Jesse Y for pointing out this problem. I have checked why the case you have provided gets degenerated. This patch needs some more work.

A solution is proposed in D9678

Hi Campbell,
probably not. Your fix should be simpler although it either does not investigate the root cause why the mouse coordinates are set to zero.

I have crafted a fix for this issue. It can be found in D9509

• SnapObjectContext allocated memory delete code included.

Julian, I have tried to incorporate your review to the best of my current knowledge. I hope that I was able to improve the patch.
Merci,
Janusch

• Revision of bugfix
• BKE_spacedata_copy included.

Thank you Germano. I gonna correct this tonight after work.

• Revision of Bugfix

Created copies of ARegion and View3D, because this memory is getting freed if viewport is collapsed.

Thx Brecht, I will resubmit a revision tonight.

Comment added

I think I found the problem and already prepared a fix. I will link the differential here.

I am not sure if this is the best possible solution. I mean it's also kind of a design decision what should happen after another viewport is merged in the one, that triggered the animation rendering? Maybe my solution is okay?

You can find my suggested fix here: https://developer.blender.org/D9334

Can't reproduce the issue anymore that I have described. Nice :)

@Philipp Oeser (lichtwerk): No problem, I was aware of it that's why I asked. I try to get familiar with the code base as as side project by helping fixing bugs. Anyway, I will go for another bug then. I dont know why the clipping did not work in my case. Unfortunately I can't test it right now because I am at work. I will take another look at it tonight.

Hey Philipp, I have looked a bit into this one. What I know so far, the bug seems to be unrelated to the mirroring as described. If you simply clip the upper half of the plane in the given file and start painting without mirroring, it already is buggy. You can't cross the y axis.