Page MenuHome

Move topbar to 3D viewport editor
AbandonedPublic

Authored by Campbell Barton (campbellbarton) on Apr 14 2019, 5:50 AM.
Tags
None
Tokens
"Yellow Medal" token, awarded by amonpaike."Like" token, awarded by YAFU."Love" token, awarded by Tetone."Love" token, awarded by pablovazquez.

Details

Summary

Still many things missing:

  • Editors other than 3D viewport
  • Toggle header visibility is not working correct
  • Move editor switch button depending on visibility
  • Auto hide when splitting 3D viewport
  • Any TODO comments in the code

The buttons organization needs work. In particular grease pencil and sculpt do not have enough space to fit all contents on typical scren resolutions. Tools with more than 1 setting often don't have enough space either and push buttons out of the center.

Some things could move to the lower header perhaps, popover menus and tool settings might be candidates. Some buttons might also not be important enough to require always being visible, and were perhaps added because there was space anyway

The downside is that hiding just the top header would still show too much stuff for secondary viewports. Instead of an option to hide upper and lower headers there could be a switch between full and compact header though, then it makes some sense to hide buttons from both.

Ref T63516

Diff Detail

Repository
rB Blender
Branch
arcpatch-D4680-3 (branched from master)
Build Status
Buildable 3375
Build 3375: arc lint + arc unit

Event Timeline

Harbormaster completed remote builds in B3323: Diff 14720.
Brecht Van Lommel (brecht) planned changes to this revision.EditedApr 14 2019, 5:50 AM

(The top header is opaque, but the theme colors make it look like it's not)

I think also in the compact header case, it would make sense to hide menus except View.

Testing with buttons shuffled around:


Still doesn't solve the case where in edit mode tool settings don't really have enough space. Also not grease pencil.

For reference, during Homestretch we agreed on following approach:

This means:

  • Keep shading options in header
  • Mode options should be in Top Bar (Things like Dyntopo etc) because they are more related to tool settings
  • Discussed with @Campbell Barton (campbellbarton) who agrees to move the viewport gizmo controls to the side to avoid 'button soup' issue.

In a later release, we could make improvements to Quad View to allow resizing and different shading modes:

To clarify the space issue, here are some screenshots with the current patch:







what about this with the new changes where will it go? this is one of the most annoying part IMO , hoping it will get it's own space that doesn't affect other parts especially the topbar/toolbar whatever you are calling it now, becaue it will cause too many flickering and hides most of th option when you do any action.

@Zino Guerr (Zino), that is not really affected by this change one way or the other.

@Zino Guerr (Zino), that is not really affected by this change one way or the other.

from the mockup seemed like one part or double header, since you guys are moving the topbar per 3d view, glad that it won't cause an affect.

IMO, Object mode switch should not be moved into that line. I think that is better to try to keep a distinction between what is more global and what is more specific.
It is also fundamental because orientation of gizmo of active tool can be different from orientation of tools called by shortcuts.
I would only move snapping and Proportional edit tool to top line for object and edit mode.
For narrow editors, users still have ability to collapse menus.

For sculpt and paint modes, I would move brush selector and mode options popover to the bottom line. Under those modes, there is no orientation or pivot point popover.

Grease Pencil have too much things. Brush Selector, Material Selector and Layer Selector in topbar.
Options in grease pencil draw mode and grease pencil edit mode are not in a popover but as quick access buttons in header.
That is unfortunate but they should move to an Options popover like automerge editing button did in Mesh Edit Mode.
That kind of solution are annoying users because they are slowing down the UI.
Paradoxically, there are lots of space in toolbar.
So, maybe some mode options could be added above tools in toolbar.
Automerge editing, Snapping, proportional editing, X-mirror, Symmetry, these things would be more efficient as buttons in toolbar.

I am unable to apply this patch cleanly - there seems to be a conflict in versioning code.

When building without, I can't seem to find a way to actually enable the top bar.

William Reynish (billreynish) requested changes to this revision.EditedApr 15 2019, 11:41 AM

Ok, was able to fix the merge issue myself and test.

Basically I think this works well, even though there are some issues to solve:

  • This region is only added to the 3D View currently. Will need to be added to the Image Editor also. (Later on should also be added to places like Sequencer and Clip editor when toolbars are added there)
  • The new Gizmo toggle button often is hanging out all alone in the middle which looks very strange. I think we should move this control next to the viewport controls, together with Overlays. If we make the Collections Visibility popover a Sidebar panel it then means we don't take any real extra space in the header.

@William Reynish (billreynish), what do you think about the lack of space for sculpt and grease pencil? Do you think it would be ok to move popovers to the lower header as in D4680#106528?

And the tool settings, is it ok if they push all the orientation and snapping settings to the right for some tools? We could move things into a popover if there are more than one or two settings.

@Brecht Van Lommel (brecht)
Just to keep things ordered, I think we should try to follow a consistent set of rules for what goes in the top bar vs the header, otherwise I feel like it becomes too random, unpredictable and jumpy if things suddenly start appearing in the headers.

This means:

Top bar: Mode, Active Tool settings, Transform tool settings, Mode Settings
Header: Menus, viewport settings.

This configuration both has a lot of logical sense and also seems to work generally well for most modes.

However, yes, there are tradeoffs and there are some situations where the above will mean there isn't always space for everything, depending on the width of the editor and the current mode. Unless we do something extra clever which will always auto-flow in some smart way, I think we should just accept that sometimes things will scroll out of view if the viewport is too narrow.

This discussion also goes back to making improvements to Quad View so that you can have one shared top bar, menu list and toolbar, but several viewports within, which is something we can look at for a later release.

We could allow for a 'dual view' and other things to make it more useful.

IMO, you should renounce to expose mode options as popovers.
Very dense popovers with lots of settings could be panels in sidebar.
If Collections popover is moved to sidebar, why Texture Slots or Grease Pencil Layers will not be moved there, too.
And for toggles which are common to almost all modes like (X-mirror, Symmetry, Live Unwrap, Automerge, Auto-IK, Dyntopo Enabling, Mask,... ) they could be buttons in toolbar (maybe with a different color theme and in an area clearly distinguished from active tool one).

  • The new Gizmo toggle button often is hanging out all alone in the middle which looks very strange. I think we should move this control next to the viewport controls, together with Overlays. If we make the Collections Visibility popover a Sidebar panel it then means we don't take any real extra space in the header.

Done rB25efa970d67b038ef6ab4d6ff2fe6a745d84a162

@Brecht Van Lommel (brecht) In versioning, you remove multiple headers, instead of RGN_TYPE_FOOTER.

Also, found one more tiny mistake I made with footer :(
In screen_refresh_headersizes I gave footer headersize.
I will take a closer look(when I get some time), I get a feeling that is a redundant function.

Testing with buttons shuffled around:


Still doesn't solve the case where in edit mode tool settings don't really have enough space. Also not grease pencil.

The proposal that I made removes the name of pencil because it doesn't have reason to be in the topbar. Also the icon. both elements uses a lot of space

User have that information in the active tools bar.

It does make sense to move the tool parameters below the menu bar, but for tools with lots of parameters like Sculpt and GPencil these all still feel cluttered. I think putting the Active Tools Settings panel from the Properties editor into some manner of (floating popup?) panel similar to @Alberto Velázquez (dcvertice)'s mockup makes the most sense.

My Sculpt and GPencil workspaces look like this, and I often have to inelegantly slide the area nearly closed to make more canvas space.

It does make sense to move the tool parameters below the menu bar, but for tools with lots of parameters like Sculpt and GPencil these all still feel cluttered. I think putting the Active Tools Settings panel from the Properties editor into some manner of (floating popup?) panel similar to @Alberto Velázquez (dcvertice)'s mockup makes the most sense.

My Sculpt and GPencil workspaces look like this, and I often have to inelegantly slide the area nearly closed to make more canvas space.

My proposal it's only a implementation of tool properties in the N-shelf panel. Like the old T-shelf. And yes, it could solve other problems.

If the toolbar can be hidden, I see an error that the Editor Type and Mode are in the toolbar.

A part I will make a new proposal.

If there is a horizontal toolbar in the editor, you should also have a vertical instance of the toolbar, for this reason I have added it to the left of the active tools. If some day active tools were added to the DopeSheet for example, I suppose it would be convenient to have the bar horizontally. So it would simply be a matter of taste to show it vertical or horizontal. Perhaps you could also add an active tool selector to the beginning of the row.

Extra
To the right of the 3D Editor, I have added five keypads to tab mode.
The first one is for the properties of the view.
The second for the editable properties of objects.
The third is for modal tools and actions, like a toolbox.
The fourth is to show the attributes of the modal actions. This could overwrite the third tab when we are modal mode.
The fifth is to edit the last action performed.

Talked w/ brecht some things to try out for the first iteration.

  • Hide toggles both at once (make it a toggle not drag resize).
  • Move object mode to the header (so we can hide the topbar without loosing functionality).
  • Make it possible to show either (header type conditionally).
  • Top left always shows viewport type switcher.

Later, add support for other editors (node, image)

  • Merge 'master' into 'arcpatch-D4680'
  • Move object mode to 3d view header
  • Merge branch 'master' into arcpatch-D4680

+1 for tabs in sidebar.
It solves problem of modal options and view options and adjust last operation.
It should free enough space in order to keep orientation and pivot into row of menus and let space for active tool.

By keeping low line as it is, just reordering a little bit shading, overlays buttons and popovers, to lower impact of an inevitable scrolling, we can have an efficient narrow header for 3D View.

In this example, menus are collapsed. But a user using pie-menu for switching shading modes could prefer to collapse shading modes buttons.
But except accepting a third row, I dpn't see a solution to allow a new comer to have a narrow 3D Viewport with menus exposed and vital info available.

  • Merge branch 'master' into arcpatch-D4680
  • Merge branch 'master' into arcpatch-D4680

The order of the controls of the proposal should be kept, because mixing the tools with the old header forces to have both header in the viewer always. All this was taken into account when developing the proposal.

The good thing about the original proposal is that it is not necessary to have the header of the area (the one that has the menu, shading, overlays, ... ) That are not something that the user is constantly using.

This allows the users to have only the header they need.

With the changes user is forced to have both headers, breaks the hierarchy of interface, its logic and in the end create problems.

i am not fan of this double header to be honest, it causes too much clutter in the viewport.
it should be clean as much possible, no need to go to the old way with nonsensical design.

The good thing about the original proposal is that it is not necessary to have the header of the area (the one that has the menu, shading, overlays, ... ) That are not something that the user is constantly using.

A new user discovering Blender will need everything (menus and popovers).

You already mention the problem of mode that could be hidden if active tool is hidden.

The same way, there is a potential problem of confusion between active tool gizmo orientation (it was move to popover for object gizmos but problem persists for 3D Cursor) and orientation of 3D View that will be used by operators called by a shortcut.

! In D4680#107231, @ronan ducluzeau (zeauro) wrote:
A new user discovering Blender will need everything (menus and popovers).

You already mention the problem of mode that could be hidden if active tool is hidden.

The same way, there is a potential problem of confusion between active tool gizmo orientation (it was move to popover for object gizmos but problem persists for 3D Cursor) and orientation of 3D View that will be used by operators called by a shortcut.

A new user could even delete the property editor, the outliner and the whole interface and leave a text editor without realizing it. And that's not why someone supports eliminating the possibilities of customizing the interface.

As far as I know the header can be hidden since 10 years, at least...

  • Add toggle for tool properties.
  • Show type switcher when tool properties is disabled.

As far as I know the header can be hidden since 10 years, at least...

Yes. And how many default screens are hiding things to new user since that time ? none.

You said that proposal is fine. I disagree.
To get rid of such topbar, user have to know lots of shortcuts for orientation snapping, mode switching but enougho to ignore active tools.
It will not close it.
To get rid of header, he needs to know what is into menus.

So customizing such proposal is just available to intermediate and advanced users.
On the other hand, keeping topbar just for active tool (as it was until now), allows fresh users that began under 2.79b to ignore active tools.

Yes. And how many default screens are hiding things to new user since that time ? none.

You said that proposal is fine. I disagree.
To get rid of such topbar, user have to know lots of shortcuts for orientation snapping, mode switching but enougho to ignore active tools.
It will not close it.
To get rid of header, he needs to know what is into menus.

So customizing such proposal is just available to intermediate and advanced users.
On the other hand, keeping topbar just for active tool (as it was until now), allows fresh users that began under 2.79b to ignore active tools.

Could you told me where I told to hide the header by default?

@Alberto Velázquez (dcvertice) , I probably misread your comment.
But try to redo your mockup with 3D Cursor using an orientation set to View.
And tell me that is not confusing to have 2 orientation that have nothing in common next to each other.
Mixing things just because these buttons are the ones you use the most, does not make an UI simple to apprehend.

2.80 has now a setting per line with things ordered into subpanels in panels.
But Topbar would be a mess of things that are not affecting same tools.

  • Add initial image editor layout (could use some work)
  • Quiet assert.

@Alberto Velázquez (dcvertice) , I probably misread your comment.
But try to redo your mockup with 3D Cursor using an orientation set to View.
And tell me that is not confusing to have 2 orientation that have nothing in common next to each other.
Mixing things just because these buttons are the ones you use the most, does not make an UI simple to apprehend.

2.80 has now a setting per line with things ordered into subpanels in panels.
But Topbar would be a mess of things that are not affecting same tools.

User will have the same problem to confuse controls with a topbar or a header. Only with a separator the effect will be the same

@ronan ducluzeau (zeauro), @Alberto Velázquez (dcvertice), quick note re: customization.

The header & tool header can only be hidden from the RMB menu unlike previously where you could accidentally drag it closed by clicking on an edge.

Once it's closed an arrow shows to expand it - accidentally customizing the UI into an unusable state shouldn't be a problem.


Committed rB54d8faa93a4dee556b12ef1ec3c607d5a72f396a closing.

Only with a separator the effect will be the same

You are right but currently there is no separator. I probably overreact.
There is a lot of space between those groups of settings into default layout workspace.

The header & tool header can only be hidden from the RMB menu unlike previously where you could accidentally drag it closed by clicking on an edge.

It looks like we can only hide Tool Settings or the whole header.

What @Alberto Velázquez (dcvertice) asked for was to be able to hide row with menus. If header means both rows, the bottom one should have a name, too.
How to hide it without hiding tool settings ?

Orientation and pivot point are now hidden when tools settings row is hidden.
Could it be possible to add a "Move to other row" item to right click menu when clicking on a menu or button or list ?
Maybe it could be automatic to preserve orientation and pivot group when tool settings is hidden.
If menus row could be hidden, it would also be mode switch that would be preserved in that case.

In reality I only ask or support to invert the positions of editor type and object interaction mode. Interaction mode in the Tool Header and Editor Type in menu header.

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedApr 19 2019, 3:56 PM

@ronan ducluzeau (zeauro) wrote:

It looks like we can only hide Tool Settings or the whole header.

First time I tried to uncheck "Show Header" I expected it to hide only header part, not tool settings. I'm not sure if this is by design, or something is not working well. Personally I would prefer to have all the visibility possibilities for the two bars individually, just to cover all the customization possibilities. Anyway I'm not sure about when one would want to have only the Header bar not visible in 3D Viewport Editor.

Rethinking my proposal based on not mixing the properties of active tools with anything, I think the top bar could be below the header. In this way the editor and the mode would always be on the top right.
In the previous screenshot, I had duplicated the properties of the active tool to show the vertical and horizontal option, in this new model I added an intercanver to avoid this duplicity.
Although in Sculpt mode there are no coordinates, snaps ... in the center of the header I have added them to see how the distribution could be in other modes.


This seems to be a more coherent solution. The header should consistently stay at the top

I think so, Duarte Farrajota.

TopBar since it is not a general bar, it reduces its width and I do not see it necessary to mix the properties of active tools with other options.
It is true that TopBar in some Mode is very empty and the Header is too full, but in all the modes of polygonal painting or grease pencil the TopBar is more than full.

To try, I made a couple of mockups with vertical and horizontal TopBar, and with the William Reynish distribution:
Top bar: Mode, Active Tool settings, Transform tool settings, Mode Settings
Header: Menus, viewport settings.



Although an interchanger could also work, the movement of the menus does not convince me.
From my point of view, if you want to lighten the Header is enough to put it over Topbar, and move the Transform tool settings from Header to Topbar, at best:
Header: Mode, Menus, viewport settings.
Top bar: Active Tool settings, Transform tool settings, Mode Settings