Make the “redo” panel also appear in the tool settings tab #57727

New Issue

William Reynish · 2018-11-08T20:00:35+01:00

William Reynish commented

2018-11-08 20:00:35 +01:00

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

We should make the 'redo' panel also appear in the Tool Settings tab in Properties: ![image.png](https://archive.blender.org/developer/F5446249/image.png)

William Reynish commented

2018-11-08 20:00:35 +01:00

Added subscribers: @WilliamReynish, @ideasman42, @RamiroCantu, @Regnas

Duarte Farrajota Ramos commented

2018-11-08 21:18:41 +01:00

Added subscriber: @DuarteRamos

Duarte Farrajota Ramos commented

2018-11-08 21:18:41 +01:00

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

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

Regnas commented

2018-11-10 18:08:38 +01:00

Yes, this will be very welcome.

Campbell Barton commented

2018-11-12 05:35:22 +01:00

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 1adfabc8c6

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 1adfabc8c6

Regnas commented

2018-11-12 16:12:01 +01:00

Added subscriber: @JacquesLucke

Regnas commented

2018-11-12 16:12:01 +01:00

@ideasman42
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 @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
Scatter Objects addon for Blender 2.8 [WIP].mp4

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.

@ideasman42 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 @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 [Scatter Objects addon for Blender 2.8 [WIP].mp4](https://archive.blender.org/developer/F5514754/Scatter_Objects_addon_for_Blender_2.8__WIP_.mp4) 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.

William Reynish commented

2018-11-12 16:25:38 +01:00

@ideasman42 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?

ronan ducluzeau commented

2018-11-12 16:37:02 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2018-11-12 16:37:02 +01:00

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.

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.

Campbell Barton commented

2018-11-12 21:15:36 +01:00

@WilliamReynish the flickering on each action seems like it could be roughly as much as #57712, 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.

@WilliamReynish the flickering on each action seems like it could be roughly as much as #57712, 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.

kursad k commented

2018-11-12 22:50:57 +01:00

Added subscriber: @kursadk

kursad k commented

2018-11-12 22:50:58 +01:00

In #57727#552957, @Regnas wrote:

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.

> In #57727#552957, @Regnas wrote: > 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.

Regnas commented

2018-11-12 23:45:58 +01:00

In #57727#553062, @kursadk wrote:

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.

> In #57727#553062, @kursadk wrote: > > 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: ![2018-11-12_23-31-54.gif](https://archive.blender.org/developer/F5520500/2018-11-12_23-31-54.gif) 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.

Campbell Barton commented

2018-11-13 00:28:12 +01:00

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

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

Regnas commented

2018-11-13 02:12:54 +01:00

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

kursad k commented

2018-11-13 03:00:25 +01:00

In #57727#553100, @Regnas wrote:

In #57727#553062, @kursadk wrote:

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 #57727#553100, @Regnas wrote: >> In #57727#553062, @kursadk wrote: >> >> 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: > ![2018-11-12_23-31-54.gif](https://archive.blender.org/developer/F5520500/2018-11-12_23-31-54.gif) > > 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

Regnas commented

2018-11-13 03:46:31 +01:00

In #57727#553130, @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.

> In #57727#553130, @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.

kursad k commented

2018-11-14 04:44:28 +01:00

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.

Regnas commented

2019-04-14 08:35:38 +02:00

Any reason why this task isn't high priority?
The redo panel in the viewport is really really intrusive imo. Also sometimes this panel becomes too big and crowded with settings, and covers a lot of the viewport, which is not efficient at all.

Any reason why this task isn't high priority? The redo panel in the viewport is really really intrusive imo. Also sometimes this panel becomes too big and crowded with settings, and covers a lot of the viewport, which is not efficient at all.

William Reynish commented

2019-04-14 08:52:34 +02:00

@ideasman42 perhaps you can say if this is realistic to sort out for 2.80 or not?

Campbell Barton commented

2019-04-14 10:35:28 +02:00

Am not convinced this is a good solution:

UI flickering (for users performing actions via shortcuts, each button press may show a different panel - causing much more flickering compared with changing active mode or tool, 2.7x avoided this by having a region for this panel - where what is proposed is to make this the top-most panel, so all panels below it will move).
Confusion from having active-tool/scene-toolsettings/active-brush/operator-redo - all mixed in one space.
Confusion from operator-redo having a reference to a spesific space in the interface that controls how an operator behaves - that isn't obvious to the user (changes in the shading mode or perspective of the 3D view can impact operator behavior).

We could discuss alternatives to this task, eg: orignaly we had this exposed from the top-bar as a popover.

This was removed because the top-bar was often too far away from the view the user was working in.

Now the top-bar is moving into the space, the redo panel could be accessed as a single icon popover (exact behavior would need to be settled on, but think something like this could work).

Am not convinced this is a good solution: - UI flickering *(for users performing actions via shortcuts, each button press may show a different panel - causing much more flickering compared with changing active mode or tool, 2.7x avoided this by having a region for this panel - where what is proposed is to make this the top-most panel, so all panels below it will move).* - Confusion from having `active-tool/scene-toolsettings/active-brush/operator-redo` - all mixed in one space. - Confusion from `operator-redo` having a reference to a spesific space in the interface that controls how an operator behaves - that isn't obvious to the user *(changes in the shading mode or perspective of the 3D view can impact operator behavior)*. ---- We could discuss alternatives to this task, eg: orignaly we had this exposed from the top-bar as a popover. This was removed because the top-bar was often too far away from the view the user was working in. Now the top-bar is moving into the space, the redo panel could be accessed as a single icon popover *(exact behavior would need to be settled on, but think something like this could work).*

Regnas commented

2019-04-14 16:15:35 +02:00

In #57727#660223, @ideasman42 wrote:
Am not convinced this is a good solution:

But this is how it literally works in every 3D software, and they never had issues or confusion, in fact, this way is far far more intuitive. I really don't understand of what confusion are we talking about here.
If someone desires to display this panel in the viewport he should assign a hotkey to the "Adjust Last Operation".

Besides, this is not about moving the redo panel, it's about making the redo panel also appear in the tool settings tab. So there's no loss of any kind here.

> In #57727#660223, @ideasman42 wrote: > Am not convinced this is a good solution: But this is how it literally works in every 3D software, and they never had issues or confusion, in fact, this way is far far more intuitive. I really don't understand of what confusion are we talking about here. If someone desires to display this panel in the viewport he should assign a hotkey to the "Adjust Last Operation". Besides, this is not about moving the redo panel, it's about making the redo panel **also** appear in the tool settings tab. So there's no loss of any kind here.

ThinkingPolygons commented

2019-04-15 00:51:56 +02:00

Added subscriber: @ThinkingPolygons

ThinkingPolygons commented

2019-04-15 00:51:56 +02:00

In #57727#660223, @ideasman42 wrote:
Am not convinced

We need this.

Every time I see the redo panel big and blocking the view like this, I wish it was in the tool settings already.

It makes perfect sense to be in the tool settings. C4D does that and it's great.
And yeah, since this proposal is to make the redo panel also appear there, nothing would really change for those that want to use it in the viewport. So I can't see why it couldn't be done.

> In #57727#660223, @ideasman42 wrote: > Am not convinced We need this. Every time I see the redo panel big and blocking the view like this, I wish it was in the tool settings already. ![x.jpg](https://archive.blender.org/developer/F6945896/x.jpg) It makes perfect sense to be in the tool settings. C4D does that and it's great. And yeah, since this proposal is to make the redo panel ***also*** appear there, nothing would really change for those that want to use it in the viewport. So I can't see why it couldn't be done.

Campbell Barton commented

2019-04-15 19:26:58 +02:00

Added subscriber: @brecht

Campbell Barton commented

2019-04-15 19:26:58 +02:00

Discussed w/ @brecht and we agreed to do the following.

Support toggling the floating redo panel.
Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden).
Add back a shortcut (using an F-Key).

This can be done once the top-bar is moved into the space.

Discussed w/ @brecht and we agreed to do the following. - Support toggling the floating redo panel. - Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden). - Add back a shortcut (using an F-Key). This can be done once the top-bar is moved into the space.

ThinkingPolygons commented

2019-04-15 19:48:44 +02:00

In #57727#661048, @ideasman42 wrote:
Discussed w/ @brecht and we agreed to do the following.

Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden).

Since the top bar is essentially a "mirror" of the tool settings tab, does it mean we will have access to that panel there as well? Otherwise it feels like a very unconventional and inconsistent way of solving it, imho.

But still, I don't understand why it can't be done like this original proposal, which is how it's done on most softwares out there.

> In #57727#661048, @ideasman42 wrote: > Discussed w/ @brecht and we agreed to do the following. > - Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden). Since the top bar is essentially a "mirror" of the tool settings tab, does it mean we will have access to that panel there as well? Otherwise it feels like a very unconventional and inconsistent way of solving it, imho. But still, I don't understand why it can't be done like this original proposal, which is how it's done on most softwares out there.

ronan ducluzeau commented

2019-04-15 22:02:52 +02:00

UI flickering (for users performing actions via shortcuts, each button press may show a different panel - causing much more flickering compared with changing active mode or tool, 2.7x avoided this by having a region for this panel - where what is proposed is to make this the top-most panel, so all panels below it will move).
Confusion from having active-tool/scene-toolsettings/active-brush/operator-redo - all mixed in one space.

If it is the only thing that annoys you, adding another Tab just for that panel would be sufficient to solve these issue.

Confusion from operator-redo having a reference to a spesific space in the interface that controls how an operator behaves - that isn't obvious to the user (changes in the shading mode or perspective of the 3D view can impact operator behavior).

That is not what a user wants and that should be considered as a bug or a fix to do.

If user performs an action in a specific view, rotates view to better perceive what he is doing and then, tweaks redo panel : action should not be drastically modified.

Updating according to view changes should not be automatic but an update provokes by a user action like pressing a button.

Anyways, that confusion exists whatever redo panel's place is.

Support toggling the floating redo panel.
Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden).
Add back a shortcut (using an F-Key).

None of these solutions are satisfying. They require an action from user to keep it open and see those settings. That is leading to a really slow UI to do any modeling work.

> UI flickering (for users performing actions via shortcuts, each button press may show a different panel - causing much more flickering compared with changing active mode or tool, 2.7x avoided this by having a region for this panel - where what is proposed is to make this the top-most panel, so all panels below it will move). > Confusion from having active-tool/scene-toolsettings/active-brush/operator-redo - all mixed in one space. If it is the only thing that annoys you, adding another Tab just for that panel would be sufficient to solve these issue. > Confusion from operator-redo having a reference to a spesific space in the interface that controls how an operator behaves - that isn't obvious to the user (changes in the shading mode or perspective of the 3D view can impact operator behavior). That is not what a user wants and that should be considered as a bug or a fix to do. If user performs an action in a specific view, rotates view to better perceive what he is doing and then, tweaks redo panel : action should not be drastically modified. Updating according to view changes should not be automatic but an update provokes by a user action like pressing a button. Anyways, that confusion exists whatever redo panel's place is. > Support toggling the floating redo panel. > Use a popover in the top-bar to show the redo panel (so there is a way to access it when it's hidden). > Add back a shortcut (using an F-Key). None of these solutions are satisfying. They require an action from user to keep it open and see those settings. That is leading to a really slow UI to do any modeling work.

Adam Friesen commented

2019-04-15 23:42:59 +02:00

Added subscriber: @Ace_Dragon

Adam Friesen commented

2019-04-15 23:42:59 +02:00

Hi.

Personally, I don't have a problem with the floating last operator panel in the bottom right corner, as it's often not far from where the operation occurred.

A couple of ideas...

Make it a panel that is summoned from the current global top bar, thereby taking care of the issue of where to adjust the last operation done in any editor.
Tack undo/redo buttons to the floating panel and show the operator options for what was done at that point in the stack (which changing would count as a new operation and disable redo).

There's always the situation that someone might complain about the amount of mouse travel required, but the only way I see to cut down on that would be to have duplicate UI items everywhere or floating windows popping up everywhere, neither of which might be desirable.

Hi. Personally, I don't have a problem with the floating *last operator* panel in the bottom right corner, as it's often not far from where the operation occurred. A couple of ideas... 1. Make it a panel that is summoned from the current global top bar, thereby taking care of the issue of where to adjust the last operation done in any editor. 2. Tack undo/redo buttons to the floating panel and show the operator options for what was done at that point in the stack (which changing would count as a new operation and disable redo). There's always the situation that someone might complain about the amount of mouse travel required, but the only way I see to cut down on that would be to have duplicate UI items everywhere or floating windows popping up everywhere, neither of which might be desirable.

Regnas commented

2019-04-16 01:13:37 +02:00

Redo panel as a popover is a bad idea imo.
The redo panel is a panel that needs to be always available/open, since it's accessed very often. Opening and closing a popover all the time won't work for that.
Making it available in the tools settings tab too is still the best solution.

Redo panel as a popover is a bad idea imo. The redo panel is a panel that needs to be always available/open, since it's accessed very often. Opening and closing a popover all the time won't work for that. Making it available in the tools settings tab too is still the best solution.

takeshi funahashi commented

2019-04-19 15:10:46 +02:00

Added subscriber: @TakeshiFunahashi

takeshi funahashi commented

2019-04-19 15:10:46 +02:00

As for me, at least current status (redo floating panel stick the left corner of bottom, in each 3d view, ) is really annoying (though I gradually accept it).

I think "moving re-do panell as free" and save the position, when save scene can offer more good experience. About many aprication which use floating panell, we can move and locate panell frell,,, (even though it can not record position, user can move them when user need )

User may not complain, if we can decide each option panell position as free.,dock or un-dockable (if lost panell,, we can reset UI as default)
user may complain, when we can not decide where we locate panell as we like. It is not about "clean UI design" (for default UI setting). it is about "flexiblility" the apricaiton offer.

Though my desktop icon are mess-up, but at least I can decide postion of icons. Messing up is my fault. I can not complain about it.
even If my desktop was clean, and short-cut icon location are well organized, I may complain, when I can not move short-cut position.
(eg always "recylce" icon must be top left corner of desktop), This is what I feel about Current blender 2.8 redo-panell. (no move) I hope to decide, "recycle-bin" position.

As for me, at least current status (redo floating panel stick the left corner of bottom, in each 3d view, ) is really annoying (though I gradually accept it). I think "moving re-do panell as free" and save the position, when save scene can offer more good experience. About many aprication which use floating panell, we can move and locate panell frell,,, (even though it can not record position, user can move them when user need ) User may not complain, if we can decide each option panell position as free.,dock or un-dockable (if lost panell,, we can reset UI as default) user may complain, when we can not decide where we locate panell as we like. It is not about "clean UI design" (for default UI setting). it is about "flexiblility" the apricaiton offer. Though my desktop icon are mess-up, but at least I can decide postion of icons. Messing up is my fault. I can not complain about it. even If my desktop was clean, and short-cut icon location are well organized, I may complain, when I can not move short-cut position. (eg always "recylce" icon must be top left corner of desktop), This is what I feel about Current blender 2.8 redo-panell. (no move) I hope to decide, "recycle-bin" position.

takeshi funahashi commented

2019-04-21 22:54:18 +02:00

now I can use "F9" redo (same as blender 2.7), but it can easy disappear without intention, when cursor locate out of the menu range.
Of course, the good thing is it can move as I need. Current ”redo" panel (bottom right coner) and "F9" have pro and con. but do same thing.

Why can not be merged them with keep both good points, as new "redo" panell, which offer more flexibility?

that means, without return old redo as "F9" ,but just offer way to move around in 3d view,for user who hope so. then offer option from preference?

1 "auto hide" (current redo panel)
2 "close , but change labell as "redo". then remain there. then when user do next action, it change labell with context of current action (extrude, rotate, move etc)

if user hope to change property, open it with click label (as same as before)

About both case, I do not know, why it need to locate as fix postion in 3d viewl. if user hope to see the panel on same place, they do not move it. but user hope to move it, may move as they need.

now I can use "F9" redo (same as blender 2.7), but it can easy disappear without intention, when cursor locate out of the menu range. Of course, the good thing is it can move as I need. Current ”redo" panel (bottom right coner) and "F9" have pro and con. but do same thing. Why can not be merged them with keep both good points, as new "redo" panell, which offer more flexibility? that means, without return old redo as "F9" ,but just offer way to move around in 3d view,for user who hope so. then offer option from preference? 1 "auto hide" (current redo panel) 2 "close , but change labell as "redo". then remain there. then when user do next action, it change labell with context of current action (extrude, rotate, move etc) ``` if user hope to change property, open it with click label (as same as before) ``` About both case, I do not know, why it need to locate as fix postion in 3d viewl. if user hope to see the panel on same place, they do not move it. but user hope to move it, may move as they need.

Olaf Haag commented

2019-05-27 23:47:41 +02:00

Added subscriber: @OlafHaag

Olaf Haag commented

2019-05-27 23:47:41 +02:00

I must say I'm already confused by the current layout and behavior. I don't quite understand why there are settings in the redo-panel that aren't in the active tools settings panel. Looking at the python commands in the console when changing these options it seems all of them are part of the arguments of the operator function in question anyway. So as a user coming from Maya I don't understand why I can't change these additional settings in the active tools panels after I activated a tool but before I use it. With the current layout I first have to use the tool to then change these additional settings afterwards in the redo panel. But since you can already set these options in the preferences for your keymap beforehand, my intuition is that you should also be able to change these for the active tool before using it.

I acknowledge that there'd be a problem deciding whether one wants to change the current operation or if changing these settings should be applied to the next use of the operator, but I think a simple "Apply" button would do the trick. When operating in the 3d view the last operation is applied when starting a new one.
In that context I like the solution of the extrude widget which uses the arrow to adjust the current operation and the plus-symbol to start a new one.

I must say I'm already confused by the current layout and behavior. I don't quite understand why there are settings in the redo-panel that aren't in the active tools settings panel. Looking at the python commands in the console when changing these options it seems all of them are part of the arguments of the operator function in question anyway. So as a user coming from Maya I don't understand why I can't change these additional settings in the active tools panels after I activated a tool but before I use it. With the current layout I first have to use the tool to then change these additional settings afterwards in the redo panel. But since you can already set these options in the preferences for your keymap beforehand, my intuition is that you should also be able to change these for the active tool before using it. I acknowledge that there'd be a problem deciding whether one wants to change the current operation or if changing these settings should be applied to the next use of the operator, but I think a simple "Apply" button would do the trick. When operating in the 3d view the last operation is applied when starting a new one. In that context I like the solution of the extrude widget which uses the arrow to adjust the current operation and the plus-symbol to start a new one. ![blender-tool_options-vs-redo.jpg](https://archive.blender.org/developer/F7072866/blender-tool_options-vs-redo.jpg)

Christoph Lohr commented

2020-02-09 13:51:39 +01:00

Added subscriber: @Thane5