Clarification for how attributes are now stored:

• Attempt to get rid of runtime DNA values (only used for values that used to be added by this patch, will post comment with clarification on how it works)
• minor cosmetic changes

@Campbell Barton (campbellbarton) Hope you don't mind if I take a look at it :), as I'm already somewhat familiar with this from D2824

The problem here is that UV maps have been scaled up extremely, which becomes visible if you zoom out inside the UV/Image Editor.

• Create separate shader for reference images
• fixed mistake with float[3]

BTW, I stumbled across what might be an error in gpu_draw.c:

It seems that keymaps are only being initialized once operator types have been, which makes it difficult to introduce those shortcuts in the tooltip(Keys not available yet in init func).
Alternatively, it would be possible to place hints below the cursor during operator execution(below the sampled pixel).

• Update for customizable keymap

• Update for master

@Sergey Sharybin (sergey) Is this ready? :)

One problem remains though: Currently(in master) you are able to adjust the newly created handles manually by keeping your mouse button pressed and moving your cursor. With this patch this cannot be done anymore because it calculates the handles for you.

Version without knife(only improved calculation):

• Replace every t

• Only use improved handle calculation when both neighbors are doubleside-aligned/free
• Fix parenting bug
• conventions: use u instead of t
• cleanup split function

@Campbell Barton (campbellbarton) What about only using the improved calculation in case both neighbors already are doubleside aligned/free and falling back to old behavior otherwise? If both neighbors are free it could then make the newly inserted point free, although that would not be necessary to achieve the same shape.

• Add accidentally removed line back in
• Clean up mask_spline_split_spline_point
• Check against FLT_EPSILON when preparing for the next recursive call

Parenting turned out to be even more 'problematic'. If both neighbors have the same parent at the same frame, there shouldn't be any problems.(Technically it has to be the initial position where the spline points has been parented, which is the case on the same frame)
If they don't - it just assumes parenting the newly created point is not possible(though parenting the same point track on different frames should be). If that is the case(whether it is because of different track points or because of different frames), it currently places the new point in respect to its neighbors' positions after the parenting(without being parented itself). This is done on every keyframe.

• Yet another parenting fix

• Fix some parenting bugs

@Sean Kennedy (hype) Thank you for the report. Mask points are parented individually. The solution I found was to check whether both neighbor points have the same parent. If they do, the new point is also going to be parented to the same track/plane. If they don't the new point won't be parented at all. Does that look like a good solution?

• Parenting
• Fix stupid #if 1 instead of #if 0 which disabled the better adjustment of ctrl+lmb handles(Can still be removed easily btw, just as I did in the last update ;))
• Change name of select_neighbors to select neighbor_handles
• Get rid of uneccessary assignment of w

• Better handles for Ctrl+click

@Sean Kennedy (hype) Here you are(this is a 64-bit build):

• Adjust feathering when cutting (Hopefully last update adding new

functionality)

@Sean Kennedy (hype) Sorry, haven't tried to get Blender building on Windows yet.

• Automatically animate new points and adjust animation of neighbor

handles

This seems to solve it

@Campbell Barton (campbellbarton) Re Ctrl-Click: The portion of the code that deals with handle placement is actually quite small and basic(maybe ~50 lines, including handle type choice?). It seems like it could be used for inserting a point, however only if the user actually directly clicks on the spline. This code is not capable of (at least appropriately) handling cases where the coords of the new point are not lying on the curve which is to be split.

• Invoke eyedropper via Ctrl+E

• use eMaskWhichHandle
• Always pass the actual size of points_array for

BKE_mask_spline_point_next_bezt

• Assign masklay->act_spline to prevent crash
• Fix wrong handling of vector handle types
• Code commenting

Cleanups

Forgot if check which caused some intersection to be sorted out although they shouldn't or the other way around

Noticed a typo. Will fix once I have access to a machine.

In D1579#34489, @Sergey Sharybin (sergey) wrote:

• Why it's done in mask_add.c and not in mask_edit.c ?

Also selects changed handles now

• Fix crash with deformed point array
• Smarter choice of handle types(doesn't just blindly use free)

• Call txt_merge_sels in delete operator
• Code-Style:
  • rename text->n_sels to text->nsels
  • post-increment in for loop

• Update for latest master
• Fix crash when reading in old files containing Texts
• Fix crash when reading in new files created with patched build
• Minor cleanup

• Patch can be applied to latest master again

• Rename poll function to 'select_poll'

• Make use of interp_v2_v2v2

• Use Doxygen-style comment for reset function

• Moved reset to separate function
• op->customdata casted (in the arguments for the reset function)

• Change tooltip to 'Sample a color from this window - Hold Ctrl for preview'

• Change tooltip to 'Sample a data-block from this window - Hold Ctrl to preview color'
• Fix some updating problems in user prefs
• Code Style: no cuddled else
• Fix problem with alpha channel

@Julian Eisel (Severin) No worries! :)
@Aaron Carlisle (Blendify) How did you do that? Just curious . . . Thx btw

• Use mutex for undistortion in node operation

Where would communication take place(In this differential? Somewhere else?)
Should fixes unrelated to this feature(e.g. weird scrollbar behavior) be done in the branch?

How do I close this diff?

• Fix knots not being selectable(if statement actually had to be (sc->flag & SC_SHOW_GRAPH_TRACKS_MOTION) == 0)

• Fix problems mentioned by @Sergey Sharybin (sergey)

I hope I got the naming convention for the poll function right.

@Aaron Carlisle (Blendify) While that might be possible(by working around shortcuts like Alt-A) similar problems to the one mentioned by @Campbell Barton (campbellbarton) occur when adding new shortcuts with the Alt key(Tab shortcuts would change). Hiding the underlines until the user hits Alt might help not having to scan the keymap on every redraw, it also makes it harder to discover the feature.
The problem I found with Ctrl-scrolling(maybe that's just me) is that it is easy to miss the tab of interest when working at a certain speed. It is at least harder than just hitting a key. Also, the direction and number of times to scroll changes depending on what tab you're in. Shortcuts remain the same and over time you might memorize them.
I don't even think number shortcuts are a bad solution. There are two issues with them, though: 1. The number icons take up space 2. We run out of numbers when we have more than 10 tabs(Like in the screenshot I attached in my prev comment).
The 2. problem could be solved by having to type multiple 'digits'. This is a patch which tries to do that. The way it counts is 0,1,2,3,4,5,6,7,8,9,0,11,22,33,44,...99,00,(Now it starts counting regularly and skips all the number it already has used)10,12,13,14,15,...21,23.... I thought two same numbers are a bit quicker to type. But this might also be a little bit confusing. A Screenshot is attached.

• Pass -1 for coord of error value

• Use Catmull-Rom-Spline (I personally think it only makes the code more complicated, but I'll let you decide :) )
• rename xn to undistorted_correspondence_element(not a fan of it, but couldn't come up with something better)
• Code Style: get rid of cuddled else

This is the patch which is based on numbers. I am not updating this diff because this might be unrelated. Or should I change the title?

• Skip hardcoded keys when assigning shortcuts

However, this is not a solution. What if the user saves with S instead of Ctrl+S? Will upload number-based approach in a comment.

Hmmm... Maybe some modifiers(ctrl, ...) would make this possible?
I even initially started the implementation with having to hover over the tabs while pressing the key before I started checking the keybindings and missed the mentioned ones...
It could also work around those keys when assigning, but that might be a little more complicated/expensive when users have custom keymaps... (It would have to scan over all the shortcuts, took a quick look, seems possible). Just an idea.

• Forgot calling selection unification code in word selection operator
• Cleaned up selection unification code(txt_merge_sels(text))

Sorry, actually meant transform_conversions.c

• Renamed to BKE_tracking_(un)distort_v2_normalized
• Proper user initialization
• Change name of height_by_pa to height_by_pixel_aspect
• Change name of undis_corners to undistorted_corners

BTW, tried to get mask parenting working which seems to use matrices. (Un)distortion could be applied before and after doing the matrix multiplication, but that might add issues with track point parenting. There also are some parenting things being done in tracking_conversions.c which seem really confusing to me. Not sure what they do.
Will update the patch with a few changes.

Looking at Scintilla, though I think it might be a useful thing, if the text editor is planned to be rewritten it might be a bad idea to do the thing twice. Took a look at the github repo, it seems like Scintilla is implemented in C++ and there is a wrapper to interface with the C code and do the drawing? I'm not sure about this, but making Scintilla work with Blender's DNA/RNA structure and C architecture might be more of hassle than just rewriting the entire thing from scratch. Plus, we might then have less trouble keeping everything in sync with their additions/fixes/improvements or providing more functionality on our own. I don't know. (Then again, Scintilla looks really powerful and we might not even have to do that)
When it comes to maintenance, I don't know if I'm familiar/experienced enough with Blender's codebase.
As it currently stands, the text editor is not really likely to be used by a developer. Working with file and especially directory structures is just a HUGE mess. As long as that problem is not addressed, developers probably won't consider writing their scripts in Blender itself. So functionality like this one might not really be interesting to anyone.
With the branch, does that mean that I should also make other improvements in the branch or should I be adding them after the merge?

• Fix cursor column updating when deleting text

Okay, fixed it(problem with cursor column updating). Will update patch soon.
As for maintenance, I do agree that supporting this is a bit overkill and time is much better spent in other areas. Not sure how to proceed.

@Campbell Barton (campbellbarton) Sorry, can't reproduce. Maybe this only happens when the selections are in a certain position . . . Could you attach a screenshot before the crash happens?
Also, intersecting selections should be unified when the operator finishes(in txt_merge_sels(text)), so that might be a bug too(haven't discovered any problems when testing though)