Make the “redo” panel also appear in the tool settings tab
Open, IncompletePublic

Tokens
"Yellow Medal" token, awarded by duarteframos."Love" token, awarded by Regnas."Love" token, awarded by razgriz286."Love" token, awarded by ThinkingPolygons."Love" token, awarded by TheRedWaxPolice.
Assigned To
None
Authored By

Description

We should make the 'redo' panel also appear in the Tool Settings tab in Properties:

Details

Type
To Do
William Reynish (billreynish) triaged this task as Normal priority.

The floating redo panel could also use some redesign, it currently looks out of place because of the toolbar.
Perhaps centered at the bottom of the viewport, ideally movable/draggable anywhere in the 3D View

Yes, this will be very welcome.

The proposed design confuses do/redo (the settings for a tool and the options to redo with different options are quite different and shouldn't be confused).

  • Basic things like how to name the panels so as not to be confusing should be resolved, even then I'm not sure naming helps much since there will be cases where the same kinds of options will be duplicated in a way that appears redundant.
  • This panel changes for every action, won't this cause annoying flickering in the interface?

Marking design as incomplete.


Even with a design that makes sure there isn't any confusion.
We had the ability to do this, but it ended up being buggy and has since been removed.

  • Operator redo sometimes depends on the screen context (window->area->region).
  • The screen context can be manipulated easily (switching workspaces, collapsing areas.. etc).
  • Overall I'm not sure this is worth the hassle to support.
  • Even if it's supported, window actions will cause it to be hidden in a way that might seem buggy from a user perspective.

If support is added back, the author needs to do it in a way that takes screen editing operations into account, unlike the previous implementation. See rB1adfabc8c62ed3f067d209511ce3d868e76c9bbd

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Incomplete.Mon, Nov 12, 5:41 AM

@Campbell Barton (campbellbarton)
To be honest, I really don't see room for confusion here.
Those settings would live in a separate and properly named panel, that alone would eliminate any kind of confusion. In fact, what I think is really confusing is the way the "Redo" panel pops up in the viewport at moment.

Annoying flickering? I don't think this is flickering at all. This is actually an expected behavior. When we are using tools we expect to see their settings in the interface.

This might be a bit unrelated, but there's this addon by @Jacques Lucke (JacquesLucke) and it's implementation is great. All the settings are in the tool settings tab, no pop ups in the viewport which is nice, because it leaves room in the viewport to show more important info, like in this case the number of instances.

https://www.youtube.com/watch?v=CTbiJiCoeu0

Imo that's how the tool system should work in Blender, it's intuitive and that's how most 3D apps work out there. The "Redo" panel in the viewport should be optional and called by F6 or something, like before.

So yeah, for me this task is very important to improve the workflow in Blender.

@Campbell Barton (campbellbarton) I don't really get the issue. Operator redo always worked before, even though it didn't necessarily appear in the editor that you launched it in. Before we also had this in the top bar which worked too. So I can't see why technically it can't be in the Properties Editor?

In 2.79, F6 panel could be called without problem of context of any area.
F6 panel does not work in a different window in 2.79.

But a workspace can support a main window and secondary windows dependent of tha main window. That should be sufficient to solve any context problem to have it by workspace.

If user is going fullscreen ; it is to use the redo panel inside the area.
I don't see interest for a user to start an action under a workspace and redoing it using this panel in another one.
But we can imagine it happens. It will not be relative to most actions accomplished in a session.
If it fails, user will be able to cancel action and repeat it in those rare cases. That would be acceptable corner cases.

If it is no more possible with 2.8, it is 2.8 design that fails.
It is is not the proposal to keep a similar functionality of a redo panel not overlapping 3DView that is annoying for user.
An F6 floating panel that can appear over an area that is not 3DView or a panel in a column that is not considered as non-overlapping area of interest that was not a problem in 2.7x to have it resizing at each action. There are years of 2.5x , 2.6x and 2.7x series to prove that such thing as a flickering problem about panel size change does not exist.
There may be problems of hidden settings but no disorientation or epilepsy crisis.
There is no reason to see it as a problem in 2.8 as long as it does not occur over the area of interest.
It is current situation that is annoying.

Yes. Mock-up is confusing. It looks like redo panel and active tool panel were fused.
These are two different things.
Operator exposed in both panel can be totally different.
Active tool can be a select tool or cursor tool.
But what will be in redo panel at that moment can be any operator called by a shortcut.

The distinction of panels by names should be obvious.
In the mock-up, panel label is active tool and operator name occurs inside the panel.
It could be same thing for redo panel. It could be titled redo last action or current action.
Or it could titled using the word "Redo " followed by operator name.
By the way it would also clarify things to have something like that used in area panel, too.

@William Reynish (billreynish) the flickering on each action seems like it could be roughly as much as T57712, maybe the panel needs to be at the bottom to prevent it making all other panels move on each action.

I'm not trying to block this suggestion, it would just be good if design tasks list shot-comings and ways to mitigate them.


Only technical issue is needs to fail gracefully when window data is freed.

This is possible of course, support for this was removed since it was a bug in unused functionality at the time.

Annoying flickering? I don't think this is flickering at all. This is actually an expected behavior. When we are using tools we expect to see their settings in the interface.

So yeah, for me this task is very important to improve the workflow in Blender.

This is annoying hell in my use case. I can fire move or scale or rotate couple times a second in edit mode, the ui elements appear and disappear so many times makes me dizzy. If all you do is move things here and there, it might not be an issue but if you like to work fast and efficient, this is not the sitaution one wants to be in. I personally find the current way of handling of hiding other stuff on the screen to show operation info to be an half baked idea.

This is annoying hell in my use case. I can fire move or scale or rotate couple times a second in edit mode, the ui elements appear and disappear so many times makes me dizzy. If all you do is move things here and there, it might not be an issue but if you like to work fast and efficient, this is not the sitaution one wants to be in. I personally find the current way of handling of hiding other stuff on the screen to show operation info to be an half baked idea.

You must be thinking about something else.
I'm talking about this kind of stuff:

I don't consider this kind of thing as flickering. This is something very natural that happens in every software that has panel that shows properties of several things.

@Regnas (Regnas) the difference is it's common to access tools directly in blender (more then you might switch tools).

You might for eg, extrude and scale many times in a row, if each action changes the UI making panels move vertically, this could be *flickering* the UI more than we'd like.

@Campbell Barton (campbellbarton) Still not a big deal for me tbh, I can live with that. But if people still think that's too annoying, then your suggestion to keep this panel at the bottom would solve that.

This is annoying hell in my use case. I can fire move or scale or rotate couple times a second in edit mode, the ui elements appear and disappear so many times makes me dizzy. If all you do is move things here and there, it might not be an issue but if you like to work fast and efficient, this is not the sitaution one wants to be in. I personally find the current way of handling of hiding other stuff on the screen to show operation info to be an half baked idea.

You must be thinking about something else.
I'm talking about this kind of stuff:

I don't consider this kind of thing as flickering. This is something very natural that happens in every software that has panel that shows properties of several things.

I was referring to what Campbell was referring (which is constant ui changes during operations), plus there is another bug report about similar issue where the viewport widgets disappear during operations, in a sense it is the same thing.

I personally would appreciate if the visible ui is less "excited" during operations. I realize it is a sticky thing to achieve while trying to organize information on the screen and keep clutter away.

thanks

In T57727#553130, @kursad k (kursadk) wrote: there is another bug report about similar issue where the viewport widgets disappear during operations, in a sense it is the same thing.

Afaik, this is not a bug, it is meant to work that way (even though there are better places to display that info). And no, it's not the same thing. The situation in the viewport with the header/widgets disappearing and stuff is quite extreme, because it's totally unexpected, unlike the contents in the properties editor. Besides, if you don't want to use that panel in the tool settings tab you always have the freedom to close it. There are no issues here.

Regnas, there are no issues to you, that is perfectly fine. Matter of minor disagreement here. I was trying to make my case about actively active tool panels. Based on the screenshot you provided, the issue is that sizing of the info box constantly changes which I personally find distractiong, however I agree that it is not as extreme as the viewport widgets issue.