Anim: Reorganize items in 'View' menus in animation and video editors #117162
No reviewers
Christoph Lendenfeld
Nathan Vegdahl
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#117162
Loading…
Reference in New Issue
No description provided.
Delete Branch "nickberckley/blender:anim-view-menu"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is the split of #116492
Changes in video editors already aproved by Richard Antalik, and they're very minimal
View menu in animation and video editors are too different from each other and unorganized. Same operators appear in different places in different editors. That makes navigation them harder, because for example you expect framing operators at the bottom because they're at the bottom in graph editor, but they're at the top in Sequencer and 3D Viewport Its important that ordering of operators match as well as possible, so that users can expect certain operators in certain places and dont spend time searching for buttons in messy menus.
I tried to match ordering to 3D viewport menu as much as possible, and also to use separators right, so that grouping of items is logical and can be shareable between editors.
I have created this grouping logic that will be useful for this PR, for matching View menus across all editors and in the future commits, when adding new items in this menu
This grouping also looks better and makes navigation easier, because it splits huge pile of toggles at the top of the menus in smaller chunks and puts operators between them, so they're esier to separate them in one glance.
Looks good to me! I'd like to get at least one more pair of eyes on it from the animation module before merging, though. @ChrisLend or @dr.sybren, could one of you take a look?
huge improvement imo
no objections to landing this
Looks good to me too.
Also curious what @ChrisLend thinks.never mind, he posted that while I was digging in to see when that "Auto-merge Keyframes" option was introduced (because I can't think why anyone would ever disable that). As it turns out, it was 16 years ago (9fdb4965a3). That commit actually introduced the auto-merging of keys as an option for the transform system.@dr.sybren there was a report recently where someone complained about the automerge messing with setting up keyframes in the driver editor. So it is useful in some cases :D
@ChrisLend I'm very curious what issues they were running into. I wonder if this is a situation where turning off automerge is more of a stopgap solution because something else isn't designed well.
@nathanvegdahl #112316: Auto-Merging keyframes in the Driver Editor has unappropriate threshold (merges keyframes that shouldnt)
@ChrisLend Thanks for the link!
It looks like the real underlying issue is my favorite topic: proper floating point handling. Currently there is a fixed 0.01 threshold for merging keys, but that's of course way too large for small values. It should probably be replaced by an approach that works in terms of relative error or floating point ulps.
But indeed, that will need to be addressed before removing the automerge toggle. And finding and handling all the cases properly may be tricky.
So in short: yeah, let's leave the option in place for now. But I still think we should remove it in the future after we have a chance to clean up floating point handling in the animation system.
@nickberckley Do you have the commit rights to land this?
Nope, this will be my first contribution in fact
This should have had at least one person from the UI team to approve.
Zoom to Borderis calledZoom Region(to match the viewport), and it should end in...because it's a modal operator that waits for input.Why is
Auto-merge Keyframes, a potentially destructive operation next toShow Sliders,Realtime Updatesand other view-related operations?@pablovazquez Zoom operator isn't part of this PR, I specifically split it off because I plan to first run it through UI module and I'm waiting to see how Harley's image editor zoom menu takes off. If its accepted I'll try to model zoom menus in other editors to that template. For now its only present in VSE and I left whatever name it already had. This PR only changed order of operators.
Auto-merge Keyframes I agree is misplaced there, but there was discussion and anim module decided to leave it there temporarily until some related things are fixed, in future it shouldn't be needed at all and can be removed
....and that is....?
The diff indicates the label
to Borderwas added in this PR:If a label is changed it's always a good idea to first see how it's done in other editors that have such feature, like the 3D Viewport.
Even if it will be removed at some point, right now it's sandwiched between
Show...properties, not ideal:Ease of access since the Timeline is usually at the bottom. It's fine to propose to reconsider this and change it for consistency, but it should have been communicated with the UI module. Especially because this same menu was changed in the latest release (4.0). It's always a good idea to check git commits around the area you're working on, to contact the people/module responsible for it about such changes.
I'm just saying that such a user-facing change should have involved people from other modules. This task doesn't even have the
Interest: User Interfacelabel. If I didn't go through the list of commits we would have missed it. @dr.sybren if this could be mentioned in the next meeting that'd be nice.Animation editors share lots of things in common with other editors, such changes should be aligned, otherwise each area grows into their own thing and feels less attached to the rest of Blender like it happened in the past.
Oh my bad, I copied some code from previous PR that I split and looks like I missed that.
Not a problem though because as I said I'm gonna do separate PR specifically for zoom menu/operators once Harley's Image Editor one is merged, I'm waiting to see if that's what we decide to go with. If not, than I'll name it whatever is decided.
Point of this PR was exactly to match other editors. Anim view menus were chaotic and didn't follow patterns that other editors did, especially 3D viewport. I don't understand how this PR makes anim editors less attached to rest of Blender, and not more attached? I've modeled grouping of operators based on other editors.
In fact I made similar graph for rest of the editors as well, to make order of operators more consistent, and have PR in my local machine, I was waiting for you to get back before I created PR, because I've noticed nobody was willing to make such decisions with you away.