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.