Page MenuHome

Move the transform info away from the header, into the viewport.
Open, NormalPublic

Description

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.

Details

Type
To Do

Event Timeline

William Reynish (billreynish) triaged this task as Normal priority.
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. https://blenderartists.org/t/any-way-to-keep-the-screen-widgets-on-the-screen-while-editing-in-edit-mode/1132726/2

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.

thanks

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...