Page MenuHome

Move the transform info away from the header, into the viewport.
Confirmed, NormalPublicTO DO

"Love" token, awarded by bastianls."Love" token, awarded by CobraA."Love" token, awarded by Shimoon."Love" token, awarded by marcuspollio."Love" token, awarded by Thane5."Love" token, awarded by cto.abid.
Assigned To
Authored By


Currently, when you transform any item in Blender, we take over the header while the transform is happening:

This makes for a vey flashing/blinking UI, where both the header and the viewport gizmo disappears and re-appears in a jarring way.

Instead, the header and viewport gizmos should stay untouched, and the transform info can be moved to the viewport along the bottom.

Event Timeline

William Reynish (billreynish) lowered the priority of this task from 90 to Normal.Nov 8 2018, 5:25 PM
kursad k (kursadk) added a comment.EditedNov 11 2018, 5:07 AM

Thanks for adding this bug.

I personally think that this "feature", "bug" or "incomplete" inplmenetation is really annoying when modelling or doing similar tasks. Icons constantly disappear and appear during edits which makes the whole 2.8 experience to be a dizzy one, at least in my use case. I tried to bring this up in a BA forum post.

I imagine that the additional information about the edits ( like the transform deltas etc) can still be shown at the bottom of the 3d viewport which seems to be just empty in general. I personally see no reason to disable UI elements to put a single line of info up there.


Maybe stating the obvious:

  • This will show as a bottom-left aligned opaque rectangle with text drawn into it.
  • It must draw ontop of everything (toolbar, redo panel, look dev etc).

Now that we have the status bar, information about operator hotkeys can be displayed at the bottom of the screen.
As for what to do with the rest of the transformation information; Why not have the operator panel pop up while you are performing an operation instead of after you confirm the operation?

Most of the information is the same anyway, and it is presented in a much cleaner way in the operator panel.
For this to work the operator panel would have to live-update, and it would have to contain extra information like axis lock: ‘along global z’ etc…
If you press escape or right click to cancel the current operator, then the operator panel could go back to displaying the previous operation.

Does anyone know a reason not to do it this way? This just makes sense to me. :)

This bug is annoying me constantly. Every time I hit G to move something I look for the axes gizmo in the top right corner to see which axis I should be moving along and the gizmo is gone. Then I hit escape, look at the gizmo, decide the direction, then hit G again. It just kills the workflow when you're up close with something and aren't sure which way you're facing.

Scenario: A user works in fullscreen without a header to get rid of distractions.

As it stands now, the modal updates won't show up unless the header is toggled on. This proposal could potentially be just as jarring for such users, unless there was an option to toggle this. Not saying I'm one of those, but it does sound like this is information would be somewhat forced on the user.

UI elements disappearing and reappearing while you're working seems pretty on-topic to me. I was going to post this as a new bug but found that it's been identified already. No bug comes anywhere close to being as annoying as being brushed off by the developers though. We're not whining. We're beta testing. I show my praise as well by donating to the development fund. Bug reports will always seem like a bunch of whining though, and there's nothing I can do about that.

It's off topic because resolving the issue described here won't address your concern.

It's off topic because resolving the issue described here won't address your concern.

My comment was in regards to the viewport header overlays disappearing while transforming. Isn't that what this bug is? I'll file a separate bug report then. Someone will just merge it with this one.

Campbell Barton (campbellbarton) I think you should read the comments more carefully.

This is from the actual description of this topic:
"This makes for a vey flashing/blinking UI, where both the header and the viewport gizmo disappears and re-appears in a jarring way."

And this is from the first reply:
"I personally think that this "feature", "bug" or "incomplete" inplmenetation is really annoying when modelling or doing similar tasks. Icons constantly disappear and appear during edits which makes the whole 2.8 experience to be a dizzy one, at least in my use case."

I really don't understand how after reading these you came to the conclusion that Russell's message is off-topic.

Anyway, I think it is unacceptable for any UI design to blink with your every move. It is very annoying and distracting. I understand that these types of bugs have been categorized under a category called UI Paper Cuts. I think this thing is your ultimate UI paper cut.

Let's say you are tweaking some vertices of a model you are working on, or you are retopologizing a mesh you sculpted.

Well, this is the thing you see every second:

It looks like a corrupt IconCache.db causing all your icons annoyingly flash on Windows.

I can't believe we need to convince devs that dealing with huge UI issues is worthwhile. If many had their way Blender would be a command-line tool only.

Yes, we should address this. We have done some work to make sure Blender 2.8 is less ‘blinky’ and ‘jumpy’ compared to 2.79, where header items would move around a lot more.

This is one of the last major areas where we still have issues with flashing or blinking. Not only is it jarring and distracting, it’s a usability issue too. It means you cannot see the axes or transform settings at a glance while transforming.

The first step could be to simply make sure that the viewport gizmo does not disappear while transforming. Next, the harder part it is to find a nicer way to deal with the transform info.

I think we could probably put this along the bottom of the viewport, perhaps.

Here's how it could look if we moved the transform info to the bottom:

In the long run it would really be nice if this information was merged with the redo-panel though. It makes no sense to have this information be duplicated.

If the operator adjustments/redo panel used the horizontal 'strip' design, one can imagine it fitting quite nicely:

This gives an example of how we could solve it by combining it with the redo panel.

while this task is clearly low priority for 2.80, but the recent conversation in the devtalk brought to my attention that this issue is also apparent in other editors like Node,Graph,Dope sheet..etc where Info Bars take over the headers, they should also be solved along this one too.

That is a very interesting idea William!
I am a bit indecisive whether or not this solution will take up a lot of space on the viewport however.
I imagine with tools such as the Inset tool where a lot of options need to be displayed, it will take up quite a lot of space, wont it?

Pressing the down button to get more information in real time while you are working on the model will especially take up a lot of space and could be quite a hindrance in my opinion, don't you think?

Zino Guerr (Zino) added a comment.EditedMay 28 2019, 12:01 AM

@Tchelet Levi (MizManFryingP) i agree with you, there is also this one in the normals menu which is probably the widest one, how are they going to fit it with the Redo Panel?the shorctus are also duplicated in the status bar which makes no sense to me...i think this needs a whole revamp from scratch.

the information of transformation (move, rotate and scale) and that of editing tools (Loop cut, bevel) appears in different places, in version 2.7x they used to be both in the same place, today it took me so much to find the amount of Bevel segments that write a bug report thinking that it was not in the interface only to find it at the last moment{F7076793}

If you're going to put yet another obscuring floating element in the content area, at least make it movable please, and provide a non-obscuring alternative, like printing that info in the status bar.

@Piotr Adamowicz (madminstrel) Agreed. I don't mind a few "obscuring floating element"s, but they should always be movable. Ideally, also resizable. And maybe dockable.

The post is becoming too complex & implement is will be so complex then this, I think.
The proposed bug/error/issue is not so complex. The solution could be simple. Just move the info from header to 3d Viewport like the info shows already:

I know it's not a perfect solution. but it can solve many problem. like hiding of 3d Gizmos while doing some operation and hiding of header...
For better improvement of the idea other speate post can be made like paper cut to gather info form users...
I think major prob/issues should be solved quickly as we can better improvements can be made time to time...

I need to comment again on this one because many people don't seem to understand the problem or it'd be fixed by now. Just don't turn off the axis gizmo while using transform tools. That's it.
Here's what the screen looks like with the cube selected. I've circled what I'm calling the axis gizmo:

And then you hit G to transform and reach for an x, y, or z key to restrict motion along an axis. You've been rotating around and aren't sure which way you're facing so you look to the axis gizmo and it's GONE:

Why? The only time I ever need the thing is when I'm transforming something and that's the only time it's hidden. It's not interfering with the info in the top left of the viewport. Why is it hidden?
That's the bug in my opinion. Can we please have someone revisit this? Pretty please? With a cherry on top?

Campbell Barton (campbellbarton) triaged this task as 30 priority.EditedOct 30 2019, 6:16 PM

Could this design be finished to the point where it's a task a developer can implement it?

  • List all tools this would apply to.
  • Show how it would look (at least the initial version - colored text could be added later).
  • Problems, and how they will be addressed...
    • Overlapping toolbar/redo panel

      do we ignore this, or try solve it?.
    • How center aligned text will manage staying centered while not jittering when numbers are adjusted.

      do we try to solve this? we can also draw text left aligned.

Hi all !

Thanks for considering this issue!
Solving it would bring a lot of benefits for the everyday use of Blender Tools, even more so if you rely on precision input.

If we focus first on the 3D viewport and Image/UV editor only, the simplest solution, as suggested before on this thread, is to merge the active Tool information with the operator adjustment/redo panel. This way, the whole header remains untouched.

In addition, the operator adjustment/redo/whatever grey bottom-left translucent panel could interact more with the actions performed. This panel could be displayed open as soon as a Tool is called (selected in the Toolbar and performed or its shortcut) and interactively (instant update of data, activated options in the other Tools panels in the header, sidebar and properties editor, etc.) show the informations needed during the action.

To know how it could be, have a look at the actual Spin Tool in the 3D viewport in Edit mode. It is the only tool that does it this way, except that it removes the navigate gizmo during the action. With the Spin Tool, the Angle, Center and Axis information is updated live, as we could expect. It would be really great to port this logic to all other Tools too ! To summerize:

In the 3D Viewport:

Object Mode:

  • Move would have its informations into the operator adjustment/redo bottom-left translucent panel, could add a entry for the total distance. Would be cool to keep the ability to toogle axes with TAB during numerical input in this panel (also for trackball and scale).
  • Rotate idem, dispay interactively the angles, axes, trackball infos.
  • Scale and Scale cage idem
  • Transform could dispay all there transforms informations in the same panel (move, rotate and scale)
  • Set 3D cursor like the Move Tool

Edit Mode: the six Tools above plus:

  • all four Extrude idem (by the way, there are a few inconsistencies with Extrude faces/region along normals and Extrude individuals faces called sometimes Shrink/Fatten in various places in the UI)
  • Inset idem (by the way, there are two more options (edge rail and select outer) in the redo panel than in the header or the shortcuts)
  • Bevel should really have all its action infos out of the status bar (reserved for tooltips). There are a looot to display, but it is already quite well organised into the redo panel.
  • Loop cut and Offset edge slide idem
  • Bisect does not have informations in the header and already updates live in the redo panel during the action, but the panel could open directly at the beginning of the action and not at the end.
  • Poly Build I do not understand how it works, sorry, so cannot comment on that, but should have the infos away from the header anyways.
  • Spin already good, but the panel could open earlier so we can set the steps e.g.
  • Smooth already updates the info in the redo panel but also uses the header.
  • Edge slide and Vertex slide idem
  • Shrink/fatten idem
  • Shear and To Sphere idem
  • Rip Edge and Rip Region idem

In the Image/UV Editor:

  • Move, Rotate and Scale like in Object mode in the 3D viewport
  • Transform could have the three transform info displayed together in the panel, as the cool white gizmo allows this three operations.

Concerning the overlapping with the Toolbar, it seems there is none, as the redo panel is pushed to the right when the Toolbar is expanded (by the way, the expansion of the Toolbar could be limited by its content, but it is for another task). The same could be said for the open sidebar with the horizontal strip design when a load of content is squized.

Concerning the animation editors, where moving elements also displays the information in the header, another solution has yet to be found. But another task can tackle that later on.

Hi all again !

Just decided to give this task some more love =D

Now that the Tool system has this great leader key (Alt) way of working, making use of the Gizmos and alterning with direct shortcuts is really efficient to my opinon.
What is still missing, to my opinon, before going into fancy and colored ribbon info bars and so on, is :

  1. easier to read informations about the action currently performed in real-time
  2. consistency between the different Tools and where they display these informations

Below I took the exemple of the Bevel Tool, as there is quite a lot of infos, but also it does not take away the 3D View Editor Header.

In red, you find the current "live" infos of the Bevel Tool in the Status Bar. It really should not be in the Status Bar (working full screen hides it, also using this space hides the shortcuts hints). Here the red rectangle highlights the Offset value but it applies to the whole Status Bar.
In orange, the Offset value you change first by default without any modifier key. It really should update "live" (like the Angle value of the Spin Tool) and not after the action is performed. Here the orangle rectangle highlights the Offset value but it applies to the whole Redo Panel.
In yellow, a would-be-great-to-have-for-future-patches.
In green, an "untouched" 3d View Editor Header, thank you !

Is there an estimate to fixing this? especially the top right corner with the navigation widgets.
Just small text at the bottom will do or combine it with the redo panel like William have said.

Aaron Carlisle (Blendify) changed the task status from Needs Information from User to Confirmed.Mon, Feb 10, 5:44 PM
Aaron Carlisle (Blendify) edited projects, added BF Blender; removed BF Blender: 2.8.