Move the transform info away from the header, into the viewport. #57712
Labels
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
No Assignees
23 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#57712
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Added subscribers: @WilliamReynish, @ideasman42, @RamiroCantu, @Regnas
Added subscriber: @kursadk
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:
Added subscriber: @Xury46
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. :)
Added subscriber: @Russ1642
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.
@Russ1642 this is off topic.
Added subscriber: @KaiJaegersen
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.
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.
Added subscriber: @frequencydistribution
This comment was removed by @frequencydistribution
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:
{F6865233, size=full}
{F6865235, size=full}
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:
{F6865279, size=full}
This gives an example of how we could solve it by combining it with the redo panel.
Added subscriber: @Znio.G
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.
Added subscriber: @AbidMaqbool
Added subscriber: @MizManFryinPan
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?
@MizManFryinPan 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.
Added subscriber: @RafaelChacon
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}
Added subscriber: @MadMinstrel
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.
Added subscriber: @0o00o0oo
@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?
Added subscriber: @JulienKaspar
Could this design be finished to the point where it's a task a developer can implement 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.
Added subscriber: @marcuspollio
This comment was removed by @marcuspollio
This comment was removed by @marcuspollio
Added subscriber: @CobraA
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.
Removed subscriber: @KaiJaegersen
Changed status from 'Needs User Info' to: 'Confirmed'
Added subscriber: @AndreaGuerra
is a real issue for me too, if yout hit G R o S you can't see any axis! :(
Hi !
I just created a post on Devtalk to discuss issues and design for this task, so it does not fill here =D
Transform informations of Tools mode coherent and mode usable
Thanks !
Added subscriber: @OlafHaag
Added subscriber: @1D_Inc
Yes, even turning alpha off doesn't help.
It's not a paper cut. It's an oozing chest wound that's starting to smell bad.
Added subscriber: @Daniel_C
Please modify this annoying feature, it is already 2021!
It is best to put the shortcut key display in the viewport, and you can turn off the display shortcut key, and then put the transformation information in the bottom status bar.
Added subscriber: @Xorrito
I agree with Xiao, best solution so far.
Added subscriber: @thinsoldier
Would it be possible to implement this as an addon while we wait for a final decision to happen within the Blender team?