Seems like preview snapping has been merged to main, thanks for all the feedback will see about adding more features to snapping in the near future.
Now Iād like to get some preliminary feedback about linked strips design before submitting the PR.
Questions:
Throughout Blender, the term ālinkedā refers to all items that are adjacent or part of the same āobjectā (vertices from the same UV island, grease pencil points from same curve, etc). Select Linked and Select Pick Linked operators already exist for the sequencer, which select all strips that directly border one another on the same channel.
Iām proposing to rename these operators to āSelect Adjacentā and āSelect Pick Adjacentā instead. My rationale is that bordering strips arenāt really ālinkedā in the same sense that GP points or UV verts are, since strips are no longer ālinkedā in this sense as soon as you move one of them.
Would people be opposed to this change? If so, we could see about calling GSoC linked strips ābound stripsā or something else.
What sounds best for a default keybind to link/unlink strips? Or is calling from the context menu fine enough, no need for a keybind?
Technical UI question for someone like @fsiddi or @pablovazquez ā Where should the link icon be situated on the strip? Before name/source/duration? After? Text labels are stored in a simple text buffer, but if Iām drawing an icon Iāll need a uiBlock and uiLayout to pass to UI_block_draw (unless thereās a simpler method), so if the icon needs to be to the right of the text thatās there right now, it might be good to think about drawing all the text in a uiBlock. For now Iāll indicate the linked property with an āLā character in the text overlays, but will make changes as necessary if I get a nice mockup
(note that all my replies are as someone who is contributing to VSE, but really knows nothing about VSE, and especially nothing about the history of it, so YMMV)
The rename of current ālinkedā to āadjacentā sounds fine to me.
Maybe start without a specific key binding (afterall, I expect 90% of use cases for linked strips to be video+audio tracks that are created when adding a movie; and for that case they should get linked automatically). But, somehow make sure that a user can set up their own shortcut key for the operator perhaps.
Not sure if āUIā things would work there; all the text labels on the strips do not go through āregularā UI system but rather through some sort of 2D UI label cache thing. That said, strips titles do have icons right now, that are drawn manually ā specifically, for āmissing mediaā strips. Create an image or a movie, and then delete their source data file, and you should get it: https://developer.blender.org/docs/release_notes/4.2/images/VSEMissingMedia.png Iād go with ālinkedā icon being in front of the label, similar to how āmissingā icons are.
Just want to mention that Select Linked operator exists for other editors that have timeline, so it will have to be much bigger change. And while changing name is easy, operators are bpy.____.select_linked and those have to be changed too. Because if you have select_linked operator which selects adjacent, and select_something (because linked is taken) operator that selects linked its gonna get real confusing. Probably too much of a breaking change. I think its worth it personally, but will need lot of people to sign. Its gonna be painful but worth it in long run to have more clear UX and less confusing names.
While ālinkā is the NLE industry standard word for binding clips together, itās also used all over Blender with different meanings, and trying to reserve it for binding VSE strips, with renaming and versioning everywhere else may too much of an uphill battle.
Looking at 3D objects, theyāre āparentedā, the selected objects to the active selected object. Moving the parent, the children will follow, but moving the children will not move the parent.
Ah, right, totally forgot about these, will definitely do this! Exact placement (before or after missing media icons?) can be the subject of an intensely heated debate later
The operators Iām talking about are bpy.ops.sequencer.select_linked() and bpy.ops.sequencer.select_linked_pick(), their implementations are restricted to VSE code.
Iām not proposing to rename any of the other āselect linkedā operators; they make sense as-is IMO:
Keyframes that are part of the same F-Curve remain part of the same F-Curve even when moving them around, so it makes sense to call these ālinkedā
Same for grease pencil points that are part of the same curve, UV verts part of the same island, bones part of the same chain, etcā¦
Two objects with the same material/mesh data/particle system etc. mean that changing the data on one changes for all of them, so it makes sense to call these ālinkedā
But strips that are next to each other arenāt linked in any of these senses.
Just proposing to rename the VSE-specific operators to .select_adjacent() and select_adjacent_pick().
I think the term āparented stripsā would suggest a one-way connotation when in reality moving any linked strip will move all of them (similar to linked object data). In this sense I think the GSoC ālinked stripsā adheres more to the concept of ālinkingā in a general Blender sense than the previous naming (ālinkedā as āstrips next to each other on the same channelā).
No, but Iāll see how it looks in combination with the link iconā¦ seems like it would help a lot in the uncommon case that you have linked strips that arenāt just on top of each other (A/V)
There is bpy.ops.action.select_linked() bpy.ops.nla.select_linked() and etc. For each editor. Each has its own operator. And they all do same thing. And you cant just rename one imo. Cant have same thing called different names in different editors. And renaming the bpy.ops name itself is breaking change (although welcomed by me)
I donāt think thereās a nla.select_linked, though, right? Unless Iām missing something. Canāt find that one in the operator search or any menus. Stuff like action.select_linked makes sense in that keyframes that are part of the same f-curve remain part of the same f-curve even when you move them aroundā¦ As soon as you move strips so that theyre no longer directly bordering each other, you cant use the sequencer.select_linked or sequencer.select_linked_pick ops anymore, which doesnāt make too much senseā¦ how are they ālinkedā then?
Versioning a change to the operator name is something Iām totally unfamiliar with so others could chime in on this point. If it is a breaking change that canāt be versioned we could see about just keeping the op name the same while changing the user-facing name. In my implementation so far thereās no separate operator for selecting linked strips, (you just select a strip thatās linked and itāll auto-select all other linked strips), so there shouldnāt be too much confusion for scripters.
Well, same argument can be made about VSE if weāre stretching definitions and we can say all strips are linked to the channel same way keyframes are to fcurve. But matter of fact is on user side they all do same thing - select keys/strips on a horizontal line. I donāt think user is looking into this much deeper than that. I agree that current term āSelect Linkedā is misleading for both usecases, because keyframes arenāt linked to the fcurve, theyāre inside it, its completely different. Thatās why Iām saying I would like to see this changed to adjacent everywhere, but anim-rigging module would have to be consulted about that.
In standard Blender terminology, objects that influence the transform of others are parented not linked.
Linked means something else.
So in this case it makes sense to use the terminology that is already used elsewhere in Blender even if it is not what is used in other programs.
When considering different names, the term would show up in menus as an imperative verb (e.g. ālink/unlinkā) and not a participle (ālinkedā), so whatever sounds best as a verb in the present tense would be great.
Join/Separate
Attach/Detach
Merge/Unmerge
Connect/Disconnect
Entangle/Disentangle
Group/Ungroup
Bind/Unbind
I like 1 since ālinking stripsā in the industry NLE sense is a little like joining together objects in Blender ā when you move one part of the object the other parts move with.
I also like 2, 4, and 7, let me know what you all think
After some conversations with Dalai, Pablo and Sergey, there is consensus that āConnect/Disconnectā is the preferred naming. Itās important to keep the meaning of ālinkingā consistent in Blender, more than aligning with the standard terminology used by other video editing software in this case.
will see about adding more features to snapping in the near future.
