From memory, we had a similar problem before in the toolshelf when trying to change brushes when renaming another one. (T49023)

Already fixed yesterday rB586c58902d9b1b1edc417728aa3e357c1e66d3a8 :)

The "good" news here is that this isn't a regression caused by the Bendy Bones changes. The custom handles feature only makes a few changes to the inputs of the calculations performed here (but not the way that the calculations responsible for doing anything of interest happen). This can be verified by disabling the custom handle refs, or by loading the files in old releases. However, this means that we still have to fix whatever it is that's causing this issue...

Not a bug.

I just checked: the code here deliberately splits the strip in half if the cursor isn't inside the strip. So, technically, it's working "as intended".

This is definitely feature request territory, so I've reclassified this as such.

@Antonio Vazquez (antoniov): You can do that when registering the callbacks. Usually you'll pass temp data like this as the last argument (ie "customdata")

In D2179#50858, @Antonio Vazquez (antoniov) wrote:

@Joshua Leung (aligorith) about adding a custom drawing handler, this is what I did in my addon, but the problem is you have to hold the interpolated stroke in some place, so save this information in GPD is not a problem because when the user confirms, the strokes are "reused" and linked to the real frame.

If we make an "on the fly" drawing, we have to calculate the interpolation for drawing and for confirm and I don't think we get any improvement on that. I have added the NULL value for readfile.c. Maybe, I need to do something similar in writefile.c to avoid saving this data.

Some general thoughts from a quick browse over what you've got:

• Conceptually, this feels a lot like what the "Breakdowner" for Armatures/Poses does. So, I'd suggest just using the same hotkeys again here, and perhaps even similar terminology. Also, just double check whether they both have the same behaviour (with regard to when it refuses to work, etc.)
• Grease Pencil frames can also have keyframe types just like normal keyframes. So, I'd suggest that frames generated here get tagged as being "Breakdown" keyframes.
• From the looks of things, it is assuming that the same set of strokes that existed in the first frame exist in the second frame? What happens if this is not the case?

You can actually just enter "Edit Strokes" mode the same way you would on any object normally. The "Enable Editing" button was removed recently (in the GP v2 branch) as it was duplicating the functionality and wasn't really needed (since both ways actually do the same thing).

Ah.. you need to drag down (to start dragging both) before starting to move left/right. Indeed this crashes. Will investigate :)

Have you checked whether this still happens for you in the current test builds (https://builder.blender.org/download)?

Currently there is not enough information here for us to figure out:

1. What is wrong? What is it currently doing? How is it not working correctly?
2. How do we reproduce this issue? What steps (preferably with a test file) are needed to get it to show this issue?
3. Windows, Linux, or Mac? Mouse or tablet?

@Antonio Vazquez (antoniov): Could you take a look to figure out what's going on here? It might be something subtle going wrong with the RNA set functions for the brush names.

View-aligned strokes should be ok because we manually tesselate and draw those, while 3d strokes are currently drawn using whatever your driver does.

Hmm... it took a second look to confirm that this is in fact happening (rBbd11d91)

Some more code review. Sorry for all the noise with separate comments, but this editor seems to get laggy if I do too many of these in one go :/

In D2115#49268, @Julian Eisel (Severin) wrote:

Second round of (partially really rough) review. Some more notes:

• Join OP: I'm not really convinced about this operator. What is the benefit of having 2 strokes joined? If it's just for having them share some settings (thickness, color, etc), wouldn't a copy_settings operator make more sense? For duplicating there's still GPENCIL_OT_duplicate_move. Also note that this breaks the 1 stroke == 1 continuous line idea, making operations such as cyclic_toggle and select_linked behave glitchy (would be good to hear feedback from users and @Joshua Leung (aligorith)).

Looking through a bit more of the code, I came across a few places where it's now iterating over the layers, then the strokes manually, so that we have access to the layer that a stroke belongs to, in order to apply parenting corrections. The problem is that this just makes maintenance worse, in that now you have to modify all the places where this happens (which happens to be most of the tools).

I've gone through "some" of the code (but not all of it yet ;). Here are some comments about stuff I've come across so far... I haven't gotten around to looking carefully at the new drawing/painting/sculpting code yet.

Currently you've got this set for some of the buttons but not others. Why is it that only those ones get set? Are there any others which may benefit? (e.g. do the other RNA update callbacks already do something similar, in cases where this sort of thing may be useful?)

Not a bug.

I'm feeling a bit silly right now, haha! XD Why oh why didn't I think of doing this when I had a look earlier!

Since Ctrl-X is commonly used in other software for "Cut", and we often have Copy and Paste (Ctrl-C, Ctrl-V) in the places where Ctrl-X is being used, I think it is asking for trouble if we keep having Ctrl-X = "Dissolve", because on the surface, they appear to do the same thing until you later try to paste. Would Shift-X be a better hotkey for this instead?

EDIT: Just noticed that Ctrl-X is used for "Dissolve" in Mesh Editing too... hrm...

Ooh.... No wonder there's this confusion! Ctrl-X is "Dissolve" not "Cut". We don't actually have a "cut" operator - just a copy and paste.