Hello all,
I’m close to finishing up preview snapping and would like some feedback on what direction to take it in.
Questions:
Should snapping be more like the 3D viewport / node editors, where the location of your mouse cursor when you press G dictates the snap target? Or should it be more like the timeline, where the initial mouse position does not affect the calculated snap target?
(I’m currently going with the latter option since it’s similar to other NLEs, but would be interested to know if people would benefit strongly by being able to dictate snap targets more “immediately” like this. If so, timeline snapping could be refactored too, to incorporate this change).
Would people want a flag that you can select to decide the source snap point based on the initial mouse position? I’m planning on making all corners and centers of selected strips to be snap sources, but with this change you would be able to select, say, only the bottom left corner as a snap source w/ the flag set and your mouse cursor closest to that corner when you start the transformation.
Would it be helpful to color separate snap types differently (using theme prefs)? Would also like some input from UI people on this. E.g., if snapping to borders, then use one color, if snapping to centers, use another.
Definately latter. That behavior in 3D viewport exists because silhouette is view-dependant and points which can be used as snap base are scattered in 3D view. For 2D images it doesnt make sense to have that complexity. It will be bad UX
Personally, I would do it in same way as it is done in VSE timeline.
This would be useful when using gizmos. For example if you snap one side of image to something and then want to snap it’s other side to something else.
Not sure about this. In 3D viewport I think you can snap to imaginary lines based on simple geometry, these items are color coded. Not sure if they are themable. For simple snap points I wouldn’t use too much colors as long as it is evident what is snapping to what.
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, haha
(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.
