Add Tabs for Movie Clip Editor #38172

Closed
opened 2014-01-12 18:01:24 +01:00 by Jonathan Williamson · 20 comments

The movie clip editor's toolbar needs tabs defined.

Resolved in 8614ed64ed

The movie clip editor's toolbar needs tabs defined. Resolved in 8614ed64ed
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Campbell Barton was assigned by Jonathan Williamson 2014-01-12 18:01:24 +01:00
Author
Member

Added subscribers: @JonathanWilliamson, @brecht, @billrey, @ideasman42

Added subscribers: @JonathanWilliamson, @brecht, @billrey, @ideasman42

Added subscriber: @sebastian_k

Added subscriber: @sebastian_k

Here's a proposal for the use of Tabs in the MCE.
I submit this here mostly for discussion, because as far as I know it adds a new UI concept to tabs. In the "Compact Tools" Panel (names are totally up for discussion as well) I have put 2 new panels, which contain the most used tools for tracking. The same buttons exist in other panels too, but since tracking is quite a linear workflow for the most part I think i makes sense to gather the tools that you use the most in a tab.
I also added a new Panel in the N-Sidebar, for the same purpose.
This should avoid a LOT of scrolling.

Either apply the patch that I added, or just paste the new space_clip.py in TextEditor and run it from there.

space_clip.py
mcetabs.diff

Here's a proposal for the use of Tabs in the MCE. I submit this here mostly for discussion, because as far as I know it adds a new UI concept to tabs. In the "Compact Tools" Panel (names are totally up for discussion as well) I have put 2 new panels, which contain the most used tools for tracking. The same buttons exist in other panels too, but since tracking is quite a linear workflow for the most part I think i makes sense to gather the tools that you use the most in a tab. I also added a new Panel in the N-Sidebar, for the same purpose. This should avoid a LOT of scrolling. Either apply the patch that I added, or just paste the new space_clip.py in TextEditor and run it from there. [space_clip.py](https://archive.blender.org/developer/F67279/space_clip.py) [mcetabs.diff](https://archive.blender.org/developer/F67280/mcetabs.diff)
Campbell Barton was unassigned by Jonathan Williamson 2014-01-12 18:10:56 +01:00
Jonathan Williamson self-assigned this 2014-01-12 18:10:56 +01:00
Author
Member

I have mixed feelings on adding tools in multiple places. It does improve the linear workflow, like you say, but it also seems a bit unnecessarily redundant.

I am not too familiar with the workflow for the MCE, so please correct me if I'm wrong on any of the below.

Would it not be more clear, and less redundant to keep all Tools in a single tab (which fits nicely on screen) and then move the clip operators into their own Movie Clip tab? Seems to me that the clip is something you set just once or twice at the beginning and then ignore it. So clicking over to the Clip tab initially to set the clip settings and then going back to the Tools tab would be quite simple and fast.

It also seems silly to me to have the Plane tab with only a single option. Particularly when it's already included in Compact Tools.

I have mixed feelings on adding tools in multiple places. It does improve the linear workflow, like you say, but it also seems a bit unnecessarily redundant. I am not too familiar with the workflow for the MCE, so please correct me if I'm wrong on any of the below. Would it not be more clear, and less redundant to keep all **Tools** in a single tab (which fits nicely on screen) and then move the clip operators into their own **Movie Clip** tab? Seems to me that the clip is something you set just once or twice at the beginning and then ignore it. So clicking over to the **Clip** tab initially to set the clip settings and then going back to the **Tools** tab would be quite simple and fast. It also seems silly to me to have the **Plane** tab with only a single option. Particularly when it's already included in **Compact Tools**.

I do agree about the PlaneTrackTab, that's silly.
However, I don't see a problem with redundant buttons if used within different tabs.
On the contrary, I think that that's something good that's now possible with tabs that has not been possible before.

If redundancy would have to be avoided I would find the benefit of tabs a bit questionable.
Currently tabs are almost the same thing as panels. They are mostly a way to show or hide panels.
The problem with that is that often panels often have a lot of buttons and options, and often it's just one or two that I would need for a certain workflow.
So let's say I want to have the Basic panel for my current task, but also need the button to generate/clear Motionpaths and the button to Repeat last history. I would have to pin these 3 panels which will lead to excessive scrolling again. It's no different than if I would simply collapse the panels.

Tabs would start to become really useful though, if I could create tabs with my own panels with only the buttons I need. I would have workflow based tabs, and of course I would have redundant buttons, but I don't think that's a problem. Well, this of course is assuming that custom panels would not move the buttons away from their original panel, but instead create an instance of that button.

Currently buttons and panels are arranged in a way so that they are grouped by some kind of logic category. That totally makes sense because that allows you to look for tools that you need in meaningful places. But once you find that one tool it might be in a place that doesn't make sense workflow-wise, because it might be in a panel with 10 more buttons so you end up scrolling a lot again.

So with the workflow based tabs concept we would have both: categorized buttons and panels, but also workflow based tabs.

The MCE is a good example to test that kind of tab concept, since it really is quite a linear workflow. The nice thing about the CompactToolTab is that it offers all the buttons that you need in one tab, and thereby also suggests a certain workflow, which works well in most situations.

But I'll try to improve that layout and will try to look into your suggestions as well.

So, to sum it up, my point is that I think tabs would be way more powerful combined with custom panels (and maybe workflow based presets)

:)

I do agree about the PlaneTrackTab, that's silly. However, I don't see a problem with redundant buttons if used within different tabs. On the contrary, I think that that's something good that's now possible with tabs that has not been possible before. If redundancy would have to be avoided I would find the benefit of tabs a bit questionable. Currently tabs are almost the same thing as panels. They are mostly a way to show or hide panels. The problem with that is that often panels often have a lot of buttons and options, and often it's just one or two that I would need for a certain workflow. So let's say I want to have the *Basic panel* for my current task, but also need the button to generate/clear *Motionpaths* and the button to *Repeat last history*. I would have to pin these 3 panels which will lead to excessive scrolling again. It's no different than if I would simply collapse the panels. Tabs would start to become really useful though, if I could create tabs with my own panels with only the buttons I need. I would have workflow based tabs, and of course I would have redundant buttons, but I don't think that's a problem. Well, this of course is assuming that custom panels would not move the buttons away from their original panel, but instead create an instance of that button. Currently buttons and panels are arranged in a way so that they are grouped by some kind of logic category. That totally makes sense because that allows you to look for tools that you need in meaningful places. But once you find that one tool it might be in a place that doesn't make sense workflow-wise, because it might be in a panel with 10 more buttons so you end up scrolling a lot again. So with the workflow based tabs concept we would have both: **categorized buttons** and panels, but also **workflow based tabs**. The MCE is a good example to test that kind of tab concept, since it really is quite a linear workflow. The nice thing about the CompactToolTab is that it offers all the buttons that you need in one tab, and thereby also suggests a certain workflow, which works well in most situations. But I'll try to improve that layout and will try to look into your suggestions as well. So, to sum it up, my point is that I think tabs would be way more powerful combined with custom panels (and maybe workflow based presets) :)
Member

Added subscriber: @Ton

Added subscriber: @Ton
Member

I would like to remind everyone that we make Blender for full-time & motivated artists, people who need the tools for daily work.

For that reason, decisions that support more efficient workflow should always be considered first.

Tabs can be used for workflow, or for navigation. When this is in conflict, just choose workflow benefits.

What is messing up in all these discussions is the effort to design a single configuration for Blender that will both be easy to learn, logical to navigate, and fast and efficient to use. In theory such UI might even exist, but we don't have the UI design talent, nor the time to achieve that now.

Instead, just make the UI flexible enough so you can make the power users totally happy, and ensure it can be just as well be configured for learning purposes.

I would like to remind everyone that we make Blender for full-time & motivated artists, people who need the tools for daily work. For that reason, decisions that support more efficient workflow should always be considered first. Tabs can be used for workflow, or for navigation. When this is in conflict, just choose workflow benefits. What is messing up in all these discussions is the effort to design a single configuration for Blender that will both be easy to learn, logical to navigate, and fast and efficient to use. In theory such UI might even exist, but we don't have the UI design talent, nor the time to achieve that now. Instead, just make the UI flexible enough so you can make the power users totally happy, and ensure it can be just as well be configured for learning purposes.

Here's an update for the tabbed MCE layout. I'm still working with Sergey on it, we plan to get rid of Distortion and Reconstruction Mode, also move some options into the header menu.
{F71106}MCE_layout_WIP.png

Here's an update for the tabbed MCE layout. I'm still working with Sergey on it, we plan to get rid of Distortion and Reconstruction Mode, also move some options into the header menu. {[F71106](https://archive.blender.org/developer/F71106/space_clip.py)}![MCE_layout_WIP.png](https://archive.blender.org/developer/F71107/MCE_layout_WIP.png)
Author
Member

@sebastian_k, I like this. Having little to no tracking experience, I cannot comment too much on the actual tool locations, but I like that's limited to just two tabs. They feel quite workflow based and makes good sense.

The only one I wonder about is "Plane Track". Shouldn't that go in the "Track" tab? Or is plane tracking normally done during the solving phase?

@sebastian_k, I like this. Having little to no tracking experience, I cannot comment too much on the actual tool locations, but I like that's limited to just two tabs. They feel quite workflow based and makes good sense. The only one I wonder about is "Plane Track". Shouldn't that go in the "Track" tab? Or is plane tracking normally done during the solving phase?

Glad you like it!
:)

PlaneTrack is a bit ambiguous. However, you do not really track a plane like with the other markers, it is kind of like a 2.5D Solution. First you track 4 or more markers and then you assign a PlaneTrack to them. Blender then solves the perspective movement of the Plane with these markers. So in my opinion it belongs more to Solution than to Track.
But maybe the Solve Tab should be renamed to Reconstruction to make it clearer? (I'm not sure though)

Glad you like it! :) PlaneTrack is a bit ambiguous. However, you do not really track a plane like with the other markers, it is kind of like a 2.5D Solution. First you track 4 or more markers and then you assign a PlaneTrack to them. Blender then solves the perspective movement of the Plane with these markers. So in my opinion it belongs more to Solution than to Track. But maybe the Solve Tab should be renamed to Reconstruction to make it clearer? (I'm not sure though)
Author
Member

Well your opinion is what really counts here, so I'm game for what you think is best :)

Any other changes? If not then I'll commit.

Well your opinion is what really counts here, so I'm game for what you think is best :) Any other changes? If not then I'll commit.

Yes, there might be more changes, especially how to arrange Tabs in Mask mode. So maybe rather wait with the commit for now. :)

Yes, there might be more changes, especially how to arrange Tabs in Mask mode. So maybe rather wait with the commit for now. :)

So here's my proposal for the mask tabs layout.
masktabs.png
space_clip.py
properties_mask_common.py
What I was not able to solve is to hide Solve Tab while in Mask mode, to activate the Mask Tab automatically when entering mask mode, and how to get rid of distortion and reconstruction modes altogether.
Maybe Sergey can help here?

So here's my proposal for the mask tabs layout. ![masktabs.png](https://archive.blender.org/developer/F75438/masktabs.png) [space_clip.py](https://archive.blender.org/developer/F75440/space_clip.py) [properties_mask_common.py](https://archive.blender.org/developer/F75441/properties_mask_common.py) What I was not able to solve is to hide Solve Tab while in Mask mode, to activate the Mask Tab automatically when entering mask mode, and how to get rid of distortion and reconstruction modes altogether. Maybe Sergey can help here?

Added subscriber: @Sergey

Added subscriber: @Sergey

Adding self to CC. Will have a look soon.

Adding self to CC. Will have a look soon.

Here's the file with Solve and Track panels hidden in the Mask mode. See poll() function of according panels. space_clip.py

I'm pretty fine with the patch. The only thing that "Tracking Settings" on the right panel shouldn't re-use show_default_expanded`. This conflicts with default settings on the left panel. But solving this would require some C magic, so once we'll agree on interface side i'll go ahead and fix this.

Which is also unclear for me now is whether we need "Reconstruction" and "Distortion" modes in clip editor or we could drop them?

Here's the file with Solve and Track panels hidden in the Mask mode. See `poll()` function of according panels. [space_clip.py](https://archive.blender.org/developer/F75528/space_clip.py) I'm pretty fine with the patch. The only thing that "Tracking Settings" on the right panel shouldn't re-use show_default_expanded`. This conflicts with default settings on the left panel. But solving this would require some C magic, so once we'll agree on interface side i'll go ahead and fix this. Which is also unclear for me now is whether we need "Reconstruction" and "Distortion" modes in clip editor or we could drop them?

We can drop the 2 other modes, since both are now available via regular track/solve tools.
One thing to think about maybe is about if we should show the track panel in mask mode, since afaik it is possible to track a mask directly.

We can drop the 2 other modes, since both are now available via regular track/solve tools. One thing to think about maybe is about if we should show the track panel in mask mode, since afaik it is possible to track a mask directly.

I don't remember we've committed mask tracking.. That was rather a local experiment.

I don't remember we've committed mask tracking.. That was rather a local experiment.
Author
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Sign in to join this conversation.
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
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#38172
No description provided.