Tool settings panel location in the UI #37450

New Issue

William Reynish · 2013-11-14T14:55:53+01:00

William Reynish commented

2013-11-14 14:55:53 +01:00

Issue Description:

The redo panel is actually global but only in the 3D view. Additionally it takes up a lot of space, doesn't really fit well in its current location and generally could use a redesign.

No Design Decisions Yet:

This has turned out to be a fairly big task and will likely go along with a bigger redesign. It's not going to be decided on immediately but we can have some further brainstorming or design work here, even if it's likely this will not be implemented in the next few months.

Proposed Solutions:

See the comments for various proposals.

Put titles in the same line as the setting, much like in the Properties Editor

**Issue Description:** The redo panel is actually global but only in the 3D view. Additionally it takes up a lot of space, doesn't really fit well in its current location and generally could use a redesign. **No Design Decisions Yet:** This has turned out to be a fairly big task and will likely go along with a bigger redesign. It's not going to be decided on immediately but we can have some further brainstorming or design work here, even if it's likely this will not be implemented in the next few months. **Proposed Solutions:** See the comments for various proposals. Put titles in the same line as the setting, much like in the Properties Editor ![redo-panel-issue-8.png](https://archive.blender.org/developer/F27206/redo-panel-issue-8.png)

William Reynish commented

2013-11-14 14:55:53 +01:00

Changed status to: 'Open'

William Reynish commented

2013-11-14 14:55:53 +01:00

Added subscriber: @billrey

blender-admin commented

2013-11-14 14:55:53 +01:00

#38069 was marked as duplicate of this issue

blender-admin commented

2013-11-14 14:55:53 +01:00

#37444 was marked as duplicate of this issue

Jonathan Williamson commented

2013-11-14 17:38:29 +01:00

Added subscriber: @JonathanWilliamson

Jonathan Williamson commented

2013-11-14 17:43:01 +01:00

I would say this is a definite improvement.

That being said, seems to me this is a much larger design decision than just the Redo Panel. If we are to consider putting the titles within the fields (which I'm not initially opposed to) then we should carefully look at the whole picture and see how universal this should be. I suspect this would improve a lot of areas, while also making some areas unreadable.

I would say this is a definite improvement. That being said, seems to me this is a much larger design decision than just the Redo Panel. If we are to consider putting the titles within the fields (which I'm not initially opposed to) then we should carefully look at the whole picture and see how universal this should be. I suspect this would improve a lot of areas, while also making some areas unreadable.

William Reynish commented

2013-11-14 18:37:07 +01:00

Carter2422:

That's already the case. In all other areas of Blender, the title and the value are both inside the number field.

The only difference is the alignment inside the number field. But that's a different issue actually :)

Carter2422: That's already the case. In all other areas of Blender, the title *and* the value are both inside the number field. The only difference is the alignment inside the number field. But that's a different issue actually :)

Brecht Van Lommel commented

2013-11-15 04:34:51 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2013-11-15 04:34:51 +01:00

If I remember correctly, the reason they are not on the same line is that there's simply not enough space in many cases. "Quad Corner Type: Straight Cut" does not fit in this narrow space. For number buttons leaving out the arrows as you did would help of course. We could try to make it smarter in detecting when there is enough space, but then you get inconsistencies between tools.

So at the moment I'm not quite sure what to do with this, if there exists some general solution that fits in the current space, or if this is something we should try to solve in a broader rethinking of where the redo panel should be in the UI and what size it should have.

If I remember correctly, the reason they are not on the same line is that there's simply not enough space in many cases. "Quad Corner Type: Straight Cut" does not fit in this narrow space. For number buttons leaving out the arrows as you did would help of course. We could try to make it smarter in detecting when there is enough space, but then you get inconsistencies between tools. So at the moment I'm not quite sure what to do with this, if there exists some general solution that fits in the current space, or if this is something we should try to solve in a broader rethinking of where the redo panel should be in the UI and what size it should have.

Paweł Łyczkowski commented

2013-11-15 11:40:10 +01:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2013-11-15 11:40:10 +01:00

I would do it like this:

Notice that putting text in aligned lists allow for quick eye-scanning.

Alternatively, Location and Rotation could take one line, with 3 number field side by side - if the number fields are capable of holding numbers wider than themselves. I noticed that when you try to move the cursor with the left and right arrow in the number field that is too narrow for a number, it actually does not scroll the number inside, which would typically take place in such scenario. It does it correctly in text fields. If the number fields behaved the same, it would allow to make some parts of the interface more concise - trying to avoid clutter at the same time of course.

I would do it like this: ![redo_01.png](https://archive.blender.org/developer/F27522/redo_01.png) Notice that putting text in aligned lists allow for quick eye-scanning. Alternatively, Location and Rotation could take one line, with 3 number field side by side - if the number fields are capable of holding numbers wider than themselves. I noticed that when you try to move the cursor with the left and right arrow in the number field that is too narrow for a number, it actually does not scroll the number inside, which would typically take place in such scenario. It does it correctly in text fields. If the number fields behaved the same, it would allow to make some parts of the interface more concise - trying to avoid clutter at the same time of course.

Jonathan Williamson commented

2013-11-15 19:28:46 +01:00

@PawelLyczkowski-1 that also looks much better, but still has the same problem of space with longer names that @brecht brought up. That being said, I'm not so sure this is avoidable. Longer names are almost always going to pose problems, and maybe that's not such a bad thing since we are also working to improve tooltips .

@PawelLyczkowski-1 that also looks much better, but still has the same problem of space with longer names that @brecht brought up. That being said, I'm not so sure this is avoidable. Longer names are almost always going to pose problems, and maybe that's not such a bad thing since we are also working to [improve tooltips ](http://developer.blender.org/T37478).

William Reynish commented

2013-11-15 21:27:38 +01:00

I think this makes sense to tackle while improving the tool settings panel in a more general way. As pointed out by @brecht in the Blender Conference UI video, the tool settings pane is actually global, and placing it in the 3D View is problematic and confusing: If you are using tools in the UV Editor, the settings for those tools appear in the 3D View - not only odd, but unusable if you have the 3D view hidden.

There are several routes to go:

Add tool settings panels to all editors
Move tool settings to entirely separate 'editor'

Make tool settings a floating

Option 1 has the disadvantage that we clutter the UI even more, adding more UI chrome that's in the way most of the time.
Option 2 is nice because that way we only have a single place for tool settings, but what if the Tool Settings editor is hidden, or you have an editor maximised?
Option 3 has the disadvantage that it obscures part of the view, but it only does so temporarily. However, it would work with all the editors, and wouldn't clutter up the UI. I'm in favour of this solution.

I think this makes sense to tackle while improving the tool settings panel in a more general way. As pointed out by @brecht in the Blender Conference UI video, the tool settings pane is actually global, and placing it in the 3D View is problematic and confusing: If you are using tools in the UV Editor, the settings for those tools appear in the 3D View - not only odd, but unusable if you have the 3D view hidden. There are several routes to go: - Add tool settings panels to all editors - Move tool settings to entirely separate 'editor' # Make tool settings a floating Option 1 has the disadvantage that we clutter the UI even more, adding more UI chrome that's in the way most of the time. Option 2 is nice because that way we only have a single place for tool settings, but what if the Tool Settings editor is hidden, or you have an editor maximised? Option 3 has the disadvantage that it obscures part of the view, but it only does so temporarily. However, it would work with all the editors, and wouldn't clutter up the UI. I'm in favour of this solution. ![tool_settings_hover.png](https://archive.blender.org/developer/F27790/tool_settings_hover.png)

Paweł Łyczkowski commented

2013-11-15 21:42:55 +01:00

@billrey

I'm in favour of option 3, but it has the problem with a floating window that can get in the way, and pops up when not needed. Here is my proposed solution:

Also, I think the name "Redo Panel" should be changed. Here is a quote from my doc explaining why:

"The Redo Panel does exactly what it name suggests, when it comes to the code - it redos the operation with different setting specified in it. But it’s function is to provide settings for operations/tools, and that’s how it’s operation is perceived. A typical user is not interested that the operation is undo’ed, and redo’ed with different settings - these are technical details. Actually calling it the “Redo Panel” creates confusion - it can be associated with the Undo Redo system, or with the “Repeat Last” operation.

So, if we are thinking about the function of this panel, it’s name should be “Operation Settings”. Also, settings of the currently used tool (ex. Knife) could also be displayed there - even though it technically does a different thing code-wise, it does the same thing function-wise."

@billrey I'm in favour of option 3, but it has the problem with a floating window that can get in the way, and pops up when not needed. Here is my proposed solution: ![shot_131115_214123.png](https://archive.blender.org/developer/F27803/shot_131115_214123.png) Also, I think the name "Redo Panel" should be changed. Here is a quote from my doc explaining why: "The Redo Panel does exactly what it name suggests, when it comes to the code - it redos the operation with different setting specified in it. But it’s `function `is to provide settings for operations/tools, and that’s how it’s operation is perceived. A typical user is not interested that the operation is undo’ed, and redo’ed with different settings - these are technical details. Actually calling it the “Redo Panel” creates confusion - it can be associated with the Undo Redo system, or with the “Repeat Last” operation. So, if we are thinking about the function of this panel, it’s name should be “Operation Settings”. Also, settings of the currently used tool (ex. Knife) could also be displayed there - even though it technically does a different thing code-wise, it does the same thing function-wise."

Jonathan Williamson commented

2013-11-15 21:46:47 +01:00

I really feel that this is one of the strongest arguments to bring back floating panels from the 2.4 days. This would put it out of the immediate scope, and definitely require some good developer time, but I really do think it's needed.

Brecht Van Lommel commented

2013-11-15 21:47:58 +01:00

I fear this is going into more post-2.70 territory, but I have a proposal for the location of this panel in my head that's a more drastic change, will try to write it down in the wiki soon.

Jonathan Williamson commented

2013-11-15 22:09:43 +01:00

I agree, this is getting into 2.7x land. After speaking with @brecht, we've agreed to mark 2.7x items at Low priority. This means we still feel they need to be tackled, just not immediately.

Brecht Van Lommel commented

2013-11-20 21:27:34 +01:00

Here's my idea on where the tool settings could fit.

Details in the Wiki

The location of tool settings is somewhat similar to a certain famous 2D image editor.

Here's my idea on where the tool settings could fit. ![ui_proposal_top_bar_reshuffle.png](https://archive.blender.org/developer/F29744/ui_proposal_top_bar_reshuffle.png) [Details in the Wiki ](http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Top_Bar_Reshuffle) The location of tool settings is somewhat similar to a certain famous 2D image editor.

Paweł Łyczkowski commented

2013-11-20 21:59:34 +01:00

@brecht This is so awesome. I was just thinking that the only solution for the tool settings is to put them in a persistent GUI element. And a great placement for the Mode button. If I will have time I will do a more flushed out mockup, to see if there is enough space.

Jonathan Williamson commented

2013-11-20 22:09:17 +01:00

Indeed, this looks very promising @brecht. I actually don't see any problems with multi-editors like you mentioned under Cons. Shouldn't this bar simply be an additional header in the 3D View?

Indeed, this looks very promising @brecht. I actually don't see any problems with multi-editors like you mentioned under **Cons**. Shouldn't this bar simply be an additional header in the 3D View?

Brecht Van Lommel commented

2013-11-20 22:31:02 +01:00

The idea was to have this global because editors other than the 3D view also have tools with settings, so we would avoid duplicating it in each editor, have enough space for tool settings, and clearly indicate that some things are global like object modes, or the last executed tool (there is only 1 tool history stack, not one per editor).

If you have one of these per editor, and you do an operation in a 3D view then the UV image bar would be empty, and if you do an operation in the UV editor the 3D view bar would be empty. Or the information would be duplicated, or you would have such a bar appearing and disappearing often.

But there are a few quite tricky things moving this to a global place, where it's not quite clear to me yet which information should be displayed there, and the argument can certainly be made to have it per editor.

The idea was to have this global because editors other than the 3D view also have tools with settings, so we would avoid duplicating it in each editor, have enough space for tool settings, and clearly indicate that some things are global like object modes, or the last executed tool (there is only 1 tool history stack, not one per editor). If you have one of these per editor, and you do an operation in a 3D view then the UV image bar would be empty, and if you do an operation in the UV editor the 3D view bar would be empty. Or the information would be duplicated, or you would have such a bar appearing and disappearing often. But there are a few quite tricky things moving this to a global place, where it's not quite clear to me yet which information should be displayed there, and the argument can certainly be made to have it per editor.

William Reynish commented

2013-11-21 11:28:11 +01:00

@brecht: Nice mockup. Makes sense.

It's nice to have a global area where global settings can go.

One issue with that I see is a potential lack of enough space to display all those things, but I'm confident that can be worked out by perhaps making it larger, or having some way to expand sections to show more?

As for the tool settings, it could go here. It would solve the issue that you loose the tool settings when the toolbar is closed, and you'd still have access to them when working in maximised view. It's non-ovrelapping too, which fits with that paradigm.

Only issue I see is that although tool settings are global in a sense, they are conceptually linked to the active tool. One would need to communicate this, so that users don't think they are global scene settings.

@brecht: Nice mockup. Makes sense. It's nice to have a global area where global settings can go. One issue with that I see is a potential lack of enough space to display all those things, but I'm confident that can be worked out by perhaps making it larger, or having some way to expand sections to show more? As for the tool settings, it could go here. It would solve the issue that you loose the tool settings when the toolbar is closed, and you'd still have access to them when working in maximised view. It's non-ovrelapping too, which fits with that paradigm. Only issue I see is that although tool settings are global in a sense, they are conceptually linked to the active tool. One would need to communicate this, so that users don't think they are global scene settings.

Bartosz Moniewski commented

2013-11-22 01:33:43 +01:00

Added subscriber: @BartekMoniewski

Diego Gangl commented

2013-11-24 00:29:51 +01:00

Added subscriber: @Januz

Diego Gangl commented

2013-11-24 00:29:51 +01:00

@brecht I like where that mockup is going.

I'd add something to your proposal.
Currently Blender decides which editor is active by cursor placement, which is sometimes very annoying (specially in the text editor). This should be changed to context on click, that way the contents of the global toobar won't change while you're moving your cursor to it (when using multiple editors).

@brecht I like where that mockup is going. I'd add something to your proposal. Currently Blender decides which editor is active by cursor placement, which is sometimes very annoying (specially in the text editor). This should be changed to context on click, that way the contents of the global toobar won't change while you're moving your cursor to it (when using multiple editors).

Brecht Van Lommel commented

2013-11-24 01:10:05 +01:00

@Januz, that's an unrelated topic, you can post about it in the wiki (a lot of people love focus follows mouse so let's not get into that here). The tool settings bar would not change contents as you move your mouse, there is only 1 global history stack, not one per editor, so only one tool with settings in there.

Paweł Łyczkowski commented

2013-11-24 15:34:45 +01:00

@brecht

Here is your mockup fleshed out more:

Additional info for this:

The narrow tab with three dots opens up a tab manager, where you can add, remove, rename and rearrange layouts - it's a modal solution, I know, I'm open to suggestions.
The "More..." button open a quick settings popup with the rest of the tool settings.
The info message stays until the user performs some kind of action (current vanishing behaviour is suboptimal). It has the ability to expand into tool settings - settings that do not fit anymore due to that are moved to the "More..." section.

@brecht Here is your mockup fleshed out more: ![mockup02_06_nodesc.png](https://archive.blender.org/developer/F32137/mockup02_06_nodesc.png) Additional info for this: - The narrow tab with three dots opens up a tab manager, where you can add, remove, rename and rearrange layouts - it's a modal solution, I know, I'm open to suggestions. - The "More..." button open a quick settings popup with the rest of the tool settings. - The info message stays until the user performs some kind of action (current vanishing behaviour is suboptimal). It has the ability to expand into tool settings - settings that do not fit anymore due to that are moved to the "More..." section.

Paweł Łyczkowski commented

2013-11-24 15:58:02 +01:00

Actually, the "..." tab can be just "+" to add new layouts, rearranging can be with drag and drop, renaming and deleting in options in RMB menu when you click on a tab. This way we avoid modality.

Brecht Van Lommel changed title from ~~The Redo panel takes up more space than it needs to.~~ to Tool settings panel location in the UI

2013-11-24 18:10:23 +01:00

Brecht Van Lommel commented

2013-11-24 18:10:42 +01:00

Edited the task title and description to reflect the current state.

Brecht Van Lommel commented

2013-11-24 18:19:17 +01:00

Added subscriber: @CodeManX

Brecht Van Lommel commented

2013-11-24 18:19:17 +01:00

◀ Merged tasks: #37444.

Bartosz Moniewski commented

2013-11-24 19:44:24 +01:00

I think making redo panel from info bar is great thing and best idea in this topic for now.
However placing editor mode of view3d in it is bad idea. What if my layout is filled with image editor, what this icon show me then? Sole purpose of this interface element is to contain all global things, program settings and recent tool tweaks. For clarity, editors modes have to be in editors headers and only there.

I think making redo panel from info bar is great thing and best idea in this topic for now. However placing editor mode of view3d in it is bad idea. What if my layout is filled with image editor, what this icon show me then? Sole purpose of this interface element is to contain all global things, program settings and recent tool tweaks. For clarity, editors modes have to be in editors headers and only there.

Diego Gangl commented

2013-11-24 23:16:04 +01:00

@brecht, sorry about that. I can see better what you meant, but there are few details I still don't understand:

As @BartekMoniewski says: what if I have a Image editor and a 3D view side by side, and want to go from the image editor to the 3D view and change the mode? (and I don't know the hotkey). Would I have to use a tool and then undo, to get into the context?
Nodes, Image, Graph and other editors don't show any settings for their commands. Will context change still be triggered by undo? What if the user want to jump into an editor and use a button in the top bar right away?

@PawelLyczkowski-1 nice work, I agree on the "..." tab. It'd be nice if the tabs were scrollable using middle-click in case the user has too many tabs, or uses large names.

@brecht, sorry about that. I can see better what you meant, but there are few details I still don't understand: - As @BartekMoniewski says: what if I have a Image editor and a 3D view side by side, and want to go from the image editor to the 3D view and change the mode? (and I don't know the hotkey). Would I have to use a tool and then undo, to get into the context? - Nodes, Image, Graph and other editors don't show any settings for their commands. Will context change still be triggered by undo? What if the user want to jump into an editor and use a button in the top bar right away? @PawelLyczkowski-1 nice work, I agree on the "..." tab. It'd be nice if the tabs were scrollable using middle-click in case the user has too many tabs, or uses large names.

Brecht Van Lommel commented

2013-11-25 00:21:59 +01:00

@Januz, the tool shown would be the active or last used tool, of which there is only one. Note that the tool settings in the 3D view right now show you tools you use in the UV and animation editors even, so this wouldn't actually be different than that.

The object mode dropdown would be persistent, not depend on what you do in an editor. I understand having the mode global is a bit weak and not appropriate for all screen layouts, I'm still not quite sure about that either. It would not show in all screen layouts, only where needed (when there is a 3D view I guess)? The object mode is not entirely right at a global level but also not entirely in the 3D view I think.

@Januz, the tool shown would be the active or last used tool, of which there is only one. Note that the tool settings in the 3D view right now show you tools you use in the UV and animation editors even, so this wouldn't actually be different than that. The object mode dropdown would be persistent, not depend on what you do in an editor. I understand having the mode global is a bit weak and not appropriate for all screen layouts, I'm still not quite sure about that either. It would not show in all screen layouts, only where needed (when there is a 3D view I guess)? The object mode is not entirely right at a global level but also not entirely in the 3D view I think.

Marco G commented

2013-11-25 18:41:55 +01:00

Added subscriber: @marcog

Diego Gangl commented

2013-11-25 22:39:15 +01:00

@brecht for the context change trigger question I was imagining this kind of scenario:
The user has a 3D view and a VSE. Let's say there's a play button in the topbar when the last used/active tool is from the VSE. Now if the user wants to move from the 3D view to the VSE and use the play button, he is forced to use some tool to trigger the change.

This is the only weak point I see in the top bar concept. It has editor parts, tools parts and global parts. Maybe the bar could be divided in 3 parts:

Mode switcher and editor tools: follows context (hover)
Tool settings: follow undo stack
Info and render buttons: remain constant

@brecht for the context change trigger question I was imagining this kind of scenario: The user has a 3D view and a VSE. Let's say there's a play button in the topbar when the last used/active tool is from the VSE. Now if the user wants to move from the 3D view to the VSE and use the play button, he is forced to use some tool to trigger the change. This is the only weak point I see in the top bar concept. It has editor parts, tools parts and global parts. Maybe the bar could be divided in 3 parts: - Mode switcher and editor tools: follows context (hover) - Tool settings: follow undo stack - Info and render buttons: remain constant

Paweł Łyczkowski commented

2013-11-25 22:48:09 +01:00

@Januz Yeah, maybe editor specific controls are not the best idea. But I see no problem with the mode switcher and the tool settings. In the scenario when you only see windows that are not affected by mode switching - well, so what? You switch a mode, nothing happens in these editors, but when you change layouts to contain some editors that do use the mode, they are in the correct one.

Bartosz Moniewski commented

2013-11-26 01:28:50 +01:00

Oh no! ;)
We are debating about interface area that show up global settings because now we trigger a tools and don't see their settings hidden in view3D. Now we came up with idea to have big mode button that changes state of some object that will be out of sight without exactly one editor. View3D, the same place when tool settings are hidden now. ;) I think this situations are similar, we are trading bad concept to weak concept.

Of course there is solution with detecting that layout have object data related editor, and then showing up mode selection button. Question is, how many editor of this kind we have? Answer is two, Viev3D and UV editor. And the real question is- What are real benefits for switching object mode without mentioned editors?

Are we keeping mode button in view3d headers? If yes, we have two exactly same buttons next to each others if someone prefer his keep headers on top. If no, how mode can be switched when we enlarge area to fullscreen with CTRL+UP?

Oh no! ;) We are debating about interface area that show up global settings because now we trigger a tools and don't see their settings hidden in view3D. Now we came up with idea to have big mode button that changes state of some object that will be out of sight without exactly one editor. View3D, the same place when tool settings are hidden now. ;) I think this situations are similar, we are trading bad concept to weak concept. Of course there is solution with detecting that layout have object data related editor, and then showing up mode selection button. Question is, how many editor of this kind we have? Answer is two, Viev3D and UV editor. And the real question is- What are **real benefits** for switching object mode without mentioned editors? Are we keeping mode button in view3d headers? If yes, we have two exactly same buttons next to each others if someone prefer his keep headers on top. If no, how mode can be switched when we enlarge area to fullscreen with CTRL+UP?

Diego Gangl commented

2013-11-26 23:49:20 +01:00

@PawelLyczkowski-1 other editors also have modes that can be switched (dope, graph, VSE). I'm not against the mode switcher or editor controls being there, I just think they should follow context.

I don't want to keep dragging the discussion over this single thing, because it's probably something that can be tested and tweaked on a prototype. If you guys decide to move on, we can go back on this when we can test it :)

@BartekMoniewski, good question. I think the toolbar would stay in fullscreen mode. The "Back to previous" button could either replace or come up besides the layout tabs.

More questions:

What happens to the info region? There were some comments about removing it on @PawelLyczkowski-1's google doc. The topmost bar would replace the info header, right?
Will headers also get a "more..." button when they can't fit their contents (for consistency)? Or should tool settings use middle-click drag too? Middle-click isn't as evident for new users, but would be consistent with the rest of the UI.
How about moving engine selection to the render settings in the properties panel? (below "display") We only change engine the time at the beginning of a project or on a particular scene, so it doesn't make sense to have it constantly on screen.

@PawelLyczkowski-1 other editors also have modes that can be switched (dope, graph, VSE). I'm not against the mode switcher or editor controls being there, I just think they should follow context. I don't want to keep dragging the discussion over this single thing, because it's probably something that can be tested and tweaked on a prototype. If you guys decide to move on, we can go back on this when we can test it :) @BartekMoniewski, good question. I think the toolbar would stay in fullscreen mode. The "Back to previous" button could either replace or come up besides the layout tabs. More questions: - What happens to the info region? There were some comments about removing it on @PawelLyczkowski-1's google doc. The topmost bar would replace the info header, right? - Will headers also get a "more..." button when they can't fit their contents (for consistency)? Or should tool settings use middle-click drag too? Middle-click isn't as evident for new users, but would be consistent with the rest of the UI. - How about moving engine selection to the render settings in the properties panel? (below "display") We only change engine the time at the beginning of a project or on a particular scene, so it doesn't make sense to have it constantly on screen.

Paweł Łyczkowski commented

2013-11-27 00:24:30 +01:00

I don't want to keep dragging the discussion over this single thing, because it's probably something that can be tested and tweaked on a prototype

Actually discussing it is cheaper, so should be favoured.

I'm not the best person to speak on this matter, since more in-depth understanding of Blender is needed for that, so feel free to ignore this.

From what @BartekMoniewski and @Januz are saying, moving the mode button out of editors seems impractical, since it really seems to be more of way to display things in the editor than an actual global mode. So the modes are local to editors. Which is weird, because it allows such strange things as accessing the edit mode of an animated object, while an animation is playing, and in effect editing the mesh of a moving object. This, amazingly, works, when it shouldn't - I would suspect that it should break most things, but it does not.

It's weird, but also liberating at the same time, so if it's not a problem code-wise, maybe it should stay.

The topmost bar would replace the info header, right?

That's how I interpret Brecht's mockup.

Will headers also get a "more..." button when they can't fit their contents (for consistency)? Or should tool settings use middle-click drag too? Middle-click isn't as evident for new users, but would be consistent with the rest of the UI.

That's a hard question. I think I would ignore discoverability this time, and leave header scrolling on MMB, and also ignore consistency and hide settings that did not fit behind a "More..." button.

How about moving engine selection to the render settings in the properties panel? (below "display") We only change engine the time at the beginning of a project or on a particular scene, so it doesn't make sense to have it constantly on screen.

Good argument, I agree.

>I don't want to keep dragging the discussion over this single thing, because it's probably something that can be tested and tweaked on a prototype Actually discussing it is cheaper, so should be favoured. I'm not the best person to speak on this matter, since more in-depth understanding of Blender is needed for that, so feel free to ignore this. From what @BartekMoniewski and @Januz are saying, moving the mode button out of editors seems impractical, since it really seems to be more of way to display things in the editor than an actual global mode. So the modes are local to editors. Which is weird, because it allows such strange things as accessing the edit mode of an animated object, while an animation is playing, and in effect editing the mesh of a moving object. This, amazingly, works, when it shouldn't - I would suspect that it should break most things, but it does not. It's weird, but also liberating at the same time, so if it's not a problem code-wise, maybe it should stay. >The topmost bar would replace the info header, right? That's how I interpret Brecht's mockup. >Will headers also get a "more..." button when they can't fit their contents (for consistency)? Or should tool settings use middle-click drag too? Middle-click isn't as evident for new users, but would be consistent with the rest of the UI. That's a hard question. I think I would ignore discoverability this time, and leave header scrolling on MMB, and also ignore consistency and hide settings that did not fit behind a "More..." button. >How about moving engine selection to the render settings in the properties panel? (below "display") We only change engine the time at the beginning of a project or on a particular scene, so it doesn't make sense to have it constantly on screen. Good argument, I agree.

Bartosz Moniewski commented

2013-11-27 18:04:38 +01:00

Another one on object mode button subject. Only real problem I find in actual solution is UV editing. UV/Image editor changes its context when object is in edit mode and have UV but... we can't enable editmode and assign UV channel to object within it. I think this editor needs more clear mode control. If I got some time I will try to write some doc about this.

My point is- If an editor is responsible for editing something we should have ability to enable this editing within it. As an example, vertex paint creates vertex channel. UV editor also need to have something similar.

@PawelLyczkowski-1 - Animation playback in different object modes is in fact weird but sometimes I encounter situations when it helps me a lot. I wish this to stay.

Another one on object mode button subject. Only real problem I find in actual solution is UV editing. UV/Image editor changes its context when object is in edit mode and have UV **but...** we can't enable editmode and assign UV channel to object within it. I think this editor needs more clear mode control. If I got some time I will try to write some doc about this. My point is- If an editor is responsible for editing something we should have ability to enable this editing within it. As an example, vertex paint creates vertex channel. UV editor also need to have something similar. @PawelLyczkowski-1 - Animation playback in different object modes is in fact weird but sometimes I encounter situations when it helps me a lot. I wish this to stay.

Warren Bahler commented

2013-12-06 17:05:17 +01:00

Added subscriber: @WarrenBahler

Diego Gangl commented

2013-12-08 23:55:42 +01:00

I read on #37443 @JonathanWilliamson's idea of combining history with the redo panel and it got me thinking how it could fit with the top bar. I made this mockup:

I think having the history in a non-persistent element makes sense, since you only need to access your history when you're backtracing or doing a large undo. Having it inside a dropdown keeps it out of the way, but still at hand and next to the tool settings.

I also tried other changes:

Changed the last tab to "+" as @PawelLyczkowski-1 mentioned
Removed the engine selection from the bar (but forgot to put it back in the properties panel :P)
Moved the info section to the upper bar. The reason is that space will almost always be more required in the lower bar, and the tab section in the upper bar will have to scroll in some way when there are too many tabs.

Multi-window support: I don't think this was discussed. What happens if the user has multiple windows? Maybe the editors could detect when they are not inside the main window and show an option in the view menu, something like "toggle topbar".

I read on #37443 @JonathanWilliamson's idea of combining history with the redo panel and it got me thinking how it could fit with the top bar. I made this mockup: ![historyMockup.png](https://archive.blender.org/developer/F37582/historyMockup.png) I think having the history in a non-persistent element makes sense, since you only need to access your history when you're backtracing or doing a large undo. Having it inside a dropdown keeps it out of the way, but still at hand and next to the tool settings. I also tried other changes: * Changed the last tab to "+" as @PawelLyczkowski-1 mentioned * Removed the engine selection from the bar (but forgot to put it back in the properties panel :P) * Moved the info section to the upper bar. The reason is that space will almost always be more required in the lower bar, and the tab section in the upper bar will have to scroll in some way when there are too many tabs. Multi-window support: I don't think this was discussed. What happens if the user has multiple windows? Maybe the editors could detect when they are not inside the main window and show an option in the view menu, something like "toggle topbar".

Paweł Łyczkowski commented

2013-12-09 00:41:00 +01:00

@Januz Yup, looks nice.

Jonathan Williamson commented

2013-12-09 17:03:06 +01:00

@Januz, yep that's exactly what I was thinking for combining settings + history.

Thomas Beck commented

2013-12-12 11:43:45 +01:00

Added subscriber: @plasmasolutions

William Reynish commented

2013-12-12 15:00:15 +01:00

This is a great discussion.

I wasn't sure if there's enough space for tool setting controls in such a slim bar. However, it appears that inside an 850px display there's space for most tool settings. It's not the cleanest layout and easily looks a bitty messy, but if we group things i slightly nicer ways I think it can work:

Here are a bunch of Edit Mode tool settings:

This is a great discussion. I wasn't sure if there's enough space for tool setting controls in such a slim bar. However, it appears that inside an 850px display there's space for most tool settings. It's not the cleanest layout and easily looks a bitty messy, but if we group things i slightly nicer ways I think it can work: Here are a bunch of Edit Mode tool settings: ![Tool_Settings_Edit_Mode_Tools.png](https://archive.blender.org/developer/F38661/Tool_Settings_Edit_Mode_Tools.png)

xrg commented

2013-12-12 15:10:41 +01:00

Added subscriber: @xrg

Bartosz Moniewski commented

2013-12-12 18:22:33 +01:00

We can include much more information and organize them better if topbar will contain two rows of items.

Big font for operator name like in @billrey mockup, then standard labels/buttons in two rows.
Numeric input fields with description (like number of cuts and smoothness) can be aligned.
Descriptions for dropdown menus on above and actual menu button below.

We can include much more information and organize them better if topbar will contain **two rows** of items. 1. Big font for operator name like in @billrey mockup, then standard labels/buttons in two rows. 2. Numeric input fields with description (like number of cuts and smoothness) can be aligned. 3. Descriptions for dropdown menus on above and actual menu button below.

William Reynish commented

2013-12-13 12:23:47 +01:00

@BartekMoniewski: I see your point, but I think we must be careful that we don't make this too big, or it'll take up too much of the screen.

Bartosz Moniewski commented

2013-12-13 12:40:03 +01:00

I understand. But see that on @brecht and @PawelLyczkowski-1 mockups this bar is already two blender-buttons height. :)

NG commented

2013-12-13 13:23:05 +01:00

Added subscriber: @NGMAT

Lsscpp commented

2013-12-13 14:40:58 +01:00

Added subscriber: @lsscpp

CodeManX commented

2013-12-16 11:38:09 +01:00

The vertical sidebars in a famous 2d app let the user toggle the width (1 row <-> 2 rows of icons / icons+labels <-> property editors).

It might work for the proposed horizontal toolbar as well: Single row by default, with extra properties off-screen * + a toggle to make it two rows with everything on screen.

* = I suggest to always place rarely used properties in a popup ("More..."), like proportional editing.

The vertical sidebars in a famous 2d app let the user toggle the width (1 row <-> 2 rows of icons / icons+labels <-> property editors). It might work for the proposed horizontal toolbar as well: Single row by default, with extra properties off-screen `*` + a toggle to make it two rows with everything on screen. `*` = I suggest to always place rarely used properties in a popup ("More..."), like proportional editing.

William Reynish commented

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

Yes, we can also do things like make sure prop. editing is just an icon-menu like in the header. This way it takes up way less space.

Lsscpp commented

2013-12-19 22:25:17 +01:00

Hi, i'd like to resume here a mockup i made a while ago on BA UI enhancements thread.

mymockup

Besides the tabs on top that Brecht copied from me (hee hee...just kiddin'), i want to point out the idea for the properties panel, where the buttons on the header act as switches for the panels below, making it possible to turn on them all (long scrolling), or just one category (as it is now), or at wish.
Hope the picture explains better than my words. (and sorry for the joke...)

Hi, i'd like to resume here a mockup i made a while ago on BA UI enhancements thread. [mymockup ](http://www.pasteall.org/pic/show.php?id=61217) Besides the tabs on top that Brecht *copied from me* (hee hee...just kiddin'), i want to point out the idea for the properties panel, where the buttons on the header act as switches for the panels below, making it possible to turn on them all (long scrolling), or just one category (as it is now), or at wish. Hope the picture explains better than my words. (and sorry for the joke...)

koil commented

2013-12-21 00:44:22 +01:00

Added subscriber: @koilz

koil commented

2013-12-21 00:44:22 +01:00

How about moving the Tool Setting panel, to the 3D View properties region, as a Panel.

That way when you use a tool from the Tools region, you wont have to scroll the settings panel.
Also if you use a Tool via the keyboard, the Setting panel would already be opened in the propeties region.
Also the advantage of this, the panel will also change size depending on what tool you use.

You could also keep it opened at the top right while using tools, convenient if required.

How about moving the Tool Setting panel, to the 3D View properties region, as a Panel. That way when you use a tool from the Tools region, you wont have to scroll the settings panel. Also if you use a Tool via the keyboard, the Setting panel would already be opened in the propeties region. Also the advantage of this, the panel will also change size depending on what tool you use. You could also keep it opened at the top right while using tools, convenient if required.

Bartosz Moniewski commented

2013-12-21 18:50:37 +01:00

@koilz This don't solve problem. We have to adjust one's editor tools in another editor which is illogical and unintuitive. Because of this operator panel should be made global as @brecht and others said.

Also I think we can reduce the importance of properties panel. Most of people have it open only because of transform menu. Those values can be placed in Properties editor (most of them is already) or maybe even new topbar if it can have two rows of buttons.

@koilz This don't solve problem. We have to adjust one's editor tools in another editor which is illogical and unintuitive. Because of this operator panel should be made global as @brecht and others said. Also I think we can reduce the importance of properties panel. Most of people have it open only because of transform menu. Those values can be placed in Properties editor (most of them is already) or maybe even new topbar if it can have two rows of buttons.

koil commented

2013-12-24 23:39:35 +01:00

Here ive added a picture which adds the tools settings, to the info editor header.

I guess the settings could be scrolled horizontal, if the later ones wanted to be accessed.

Im ok with this or the previous one i suggested.

Here ive added a picture which adds the tools settings, to the info editor header. ![info_bar.PNG](https://archive.blender.org/developer/F55981/info_bar.PNG) I guess the settings could be scrolled horizontal, if the later ones wanted to be accessed. Im ok with this or the previous one i suggested.

Brecht Van Lommel commented

2014-01-08 23:17:13 +01:00

Added subscribers: @scottyp, @ionarn

Brecht Van Lommel commented

2014-01-08 23:17:13 +01:00

◀ Merged tasks: #38069.

michael knubben commented

2014-01-14 12:15:45 +01:00

Added subscriber: @michaelknubben

Sv. Lockal commented

2014-01-17 05:43:17 +01:00

Added subscriber: @Lockal

Yousef Harfoush commented

2014-01-17 15:38:43 +01:00

Added subscriber: @bat3a

Yousef Harfoush commented

2014-01-17 15:38:43 +01:00

how about NOT having a tool setting panel!

here is how:

click or press shortcut to activate a tool(using #37554 tool workflow)
display all the setting one by one while performing the tool
automatically go to the next setting with a click
a simple way to go back and forth with mouse scroll
if scroll is not fast enough, you can middle click to get a list of the options near mouse floating [wip]
visual feed back to each setting (rulers etc...) [can be long sometimes]

enter or space or right click to terminate the tool at any step (using the default value for the remaining steps)

advantages:

very fast to know what an option is for from the visual feedback (for newbies)
great focus on each option instead of searching for something (for complex and weird setting like sapling or ivygen...), while still having a simple way to terminate immediately for using the defaults (for experts)

i think a mocap is needed to get a good feeling of what is this about (i'll try to do one iAw) if anyone see's it's applicable.
what ever the final solution maybe it will be with some shortcoming, the idea is to have the minimum shortcoming.

how about **NOT** having a tool setting panel! here is how: - click or press shortcut to activate a tool(using #37554 tool workflow) - display all the setting one by one while performing the tool - automatically go to the next setting with a click - a simple way to go back and forth with mouse scroll - if scroll is not fast enough, you can middle click to get a list of the options near mouse floating [wip] - visual feed back to each setting (rulers etc...) [can be long sometimes] # enter or space or right click to terminate the tool at any step (using the default value for the remaining steps) advantages: - very fast to know what an option is for from the visual feedback (for newbies) - great focus on each option instead of searching for something (for complex and weird setting like sapling or ivygen...), while still having a simple way to terminate immediately for using the defaults (for experts) i think a mocap is needed to get a good feeling of what is this about (i'll try to do one iAw) if anyone see's it's applicable. what ever the final solution maybe it will be with some shortcoming, the idea is to have the minimum shortcoming.

Jonathan Williamson commented

2014-01-17 16:18:03 +01:00

@bat3a, that proposal fails in one serious situation. When using the same tool repetitiously with the same settings. Your option for confirming/canceling at any point would help solve this, except then how would the user be aware that they could skip ahead like that? That's not a very easy thing to illustrate clearly during an operation and I initially think it'd simply end up confusing the user.

Yousef Harfoush commented

2014-01-17 17:33:29 +01:00

@JonathanWilliamson

the same way the user now is able to predict how to use current tools, let me explain:

for example the add loop tool:
user presses ctrl+p
tool activates and line indication appears (notice that there is no way to indicate that scroll changes line count, unless by accident, or experience!)
user clicks to confirm, (but it does not end!)
it moves to the next option which is where to put the lines (when you would expect it will terminate!)
clicks again to confirm ending (which is not consistent with most tools that terminate 1st click!)

this remains the same with the new proposal, but it goes over all the options, solves some issues:

click to advance in options (click after the last option to end)
scroll back/forward if you need to change prev./next option
mouse move to change current option value, add shift to snap, alt to refine, ctrl to use scroll
middle click/enter to immediately exit at any option (leaving the rest to defaults),add ctrl to repeat
space to display options as arc and still able to scroll or click the option u need
r-click/esc to cancel

this fixes consistency because all the tools end at last option
visual feedback of options indicate that the user still in tool mode (u could even give lighter/next color to each option step till you reach the "black" end which also helps with remembering critical options by recalling option color with option)

the flawed with brecht's top bar options like PS, is it is as good as the current way (which we are trying to get rid of), plus top bar is more far-away than the left bar, also long-name options problem are still present.

and i say again this kind of proposal is hard to grasp how it will be (practical), unless it is used by users and see how fast (or slow) its learning/remembering process, and most proposals here too are prone to this assessment.

the proposal is still refining in my mind at the moment, but the solid steps are there.

@JonathanWilliamson the same way the user now is able to predict how to use current tools, let me explain: for example the add loop tool: user presses ctrl+p tool activates and line indication appears (notice that there is no way to indicate that scroll changes line count, unless by accident, or experience!) user clicks to confirm, (but it does not end!) it moves to the next option which is where to put the lines (when you would expect it will terminate!) clicks again to confirm ending (which is not consistent with most tools that terminate 1st click!) this remains the same with the new proposal, but it goes over all the options, solves some issues: click to advance in options (click after the last option to end) scroll back/forward if you need to change prev./next option mouse move to change current option value, add shift to snap, alt to refine, ctrl to use scroll middle click/enter to immediately exit at any option (leaving the rest to defaults),add ctrl to repeat space to display options as arc and still able to scroll or click the option u need r-click/esc to cancel this fixes consistency because all the tools end at last option visual feedback of options indicate that the user still in tool mode (u could even give lighter/next color to each option step till you reach the "black" end which also helps with remembering critical options by recalling option color with option) the flawed with brecht's top bar options like PS, is it is as good as the current way (which we are trying to get rid of), plus top bar is more far-away than the left bar, also long-name options problem are still present. and i say again this kind of proposal is hard to grasp how it will be (practical), unless it is used by users and see how fast (or slow) its learning/remembering process, and most proposals here too are prone to this assessment. the proposal is still refining in my mind at the moment, but the solid steps are there.

Diego Gangl commented

2014-01-17 18:36:01 +01:00

"(notice that there is no way to indicate that scroll changes line count, unless by accident, or experience!)"
It's explained in the header when you use the tool.

"user clicks to confirm, (but it does not end!)"
It enters edge slide, which is another tool. It's a little inconsistent but it lets you work faster since you usually want to move a loop after you made it.

Your proposal sounds kind of like a wizard? How would it work for things like Knife, Extrude or Translate (move)?
Maybe it'd be easier to see if you made some mockups of how it would flow.

"(notice that there is no way to indicate that scroll changes line count, unless by accident, or experience!)" It's explained in the header when you use the tool. "user clicks to confirm, (but it does not end!)" It enters edge slide, which is another tool. It's a little inconsistent but it lets you work faster since you usually want to move a loop after you made it. Your proposal sounds kind of like a wizard? How would it work for things like Knife, Extrude or Translate (move)? Maybe it'd be easier to see if you made some mockups of how it would flow.

Bartosz Moniewski commented

2014-01-17 18:45:23 +01:00

I think this is bad design. Hidden tool settings was the main reason of this task and Brech proposal. I can't picture how ridiculously hard working with blender will be witouh looking at tool setting in one place and tweak them.

Also this design is in conflict with blender operators design... Or multiplies user input hundred times.
No we translate objects by pressing G, moving cursor, click and then we can tweak values in operator panel. In your scenario to move single vertex and set everything at the same time user will have to:

press G
input x vector value and click
input y vector value and click
input z vector value and click
set constrain axises (press X and/or Y and/or Z ) and click
choose operation orientation from menu...
etc etc etc...

I think this is bad design. Hidden tool settings was the main reason of this task and Brech proposal. I can't picture how ridiculously hard working with blender will be witouh looking at tool setting in one place and tweak them. Also this design is in conflict with blender operators design... Or multiplies user input hundred times. No we translate objects by pressing G, moving cursor, click and then we can tweak values in operator panel. In your scenario to move single vertex and set everything at the same time user will have to: 1. press G 2. input x vector value and click 3. input y vector value and click 4. input z vector value and click 5. set constrain axises (press X and/or Y and/or Z ) and click 6. choose operation orientation from menu... etc etc etc...

Yousef Harfoush commented

2014-01-18 00:07:20 +01:00

@Januz:
yeah in the middle of a bunch of buttons in nowhere on an easy accidentally closeable bar.

  It enters edge slide, which is another tool

which is even a greater flawed, and changing it to using tools options.

now for knife it is the same, u can just press space like u usually do, but also u can go over all the options interactively.

it needs a mockup for sure, but i need to test if the all tools would work 1st.

@BartekMoniewski

at tool setting in one place and tweak them.

you still can do that :)

In your scenario to move single vertex and set everything at the same time user will have to...

no you will interact the same and more visually, having to see all the options doesn't mean x, y, z each alone, moving is a single step with mouse.

@Januz: yeah in the middle of a bunch of buttons in nowhere on an easy accidentally closeable bar. ``` It enters edge slide, which is another tool ``` which is even a greater flawed, and changing it to using tools options. now for knife it is the same, u can just press space like u usually do, but also u can go over all the options interactively. it needs a mockup for sure, but i need to test if the all tools would work 1st. @BartekMoniewski ``` at tool setting in one place and tweak them. ``` you still can do that :) ``` In your scenario to move single vertex and set everything at the same time user will have to... ``` no you will interact the same and more visually, having to see all the options doesn't mean x, y, z each alone, moving is a single step with mouse.

Vlad Mafteiu Scai commented

2014-07-03 08:55:53 +02:00

Added subscriber: @00Ghz

ronan ducluzeau commented

2014-07-03 16:26:52 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2014-07-03 16:26:52 +02:00

For 2.5x, I made a mockup that looks like Brecth proposal. But it was for a very minimal UI with a closed toolshelf.

I also made another mockup with an intermediate UI about the opposite. (Tools as icons in a vertical band / Tools settings in right column)

We have tabs, now. From my point of view, changing redo panel as a properties colum tab solves all blockers.

Properties column exists in every editor. It is as general as header.
Contrary to floating panel, it does not give undesired pop ups or disappear.
It would display more settings in an editor with small width than an header and as many as actually in an editor with small height.
But much more than actually in a big editor like default 3DView.
There is no need to display tool settings and editor properties at same time.

I know the reply:
"An editor with 2 columns opened is cluttered."
As is nobody never changes settings in Properties Column and only use Toolshelf or F6 panel would be suppresed by that.
Toolshelf would probably be useless when Pie Menus would have been generalized to everything.
Imho, adding a pinned floating panel to the already existing 2 columns would made a worst cluterred UI.

Ideal solution would be to have an UI of regions that adapts itself to vertical column or horizontal small bands and detachable regions, dockable tabs. But it would require icons for all tools and autozooming to display all settings correctly.

If there is a return of floating panels, I prefer that it would not be one per tab. But preferably, an automatic resized version of current columns.

For 2.5x, I made a mockup that looks like Brecth proposal. But it was for a very minimal UI with a closed toolshelf. I also made another mockup with an intermediate UI about the opposite. (Tools as icons in a vertical band / Tools settings in right column) We have tabs, now. From my point of view, changing redo panel as a properties colum tab solves all blockers. Properties column exists in every editor. It is as general as header. Contrary to floating panel, it does not give undesired pop ups or disappear. It would display more settings in an editor with small width than an header and as many as actually in an editor with small height. But much more than actually in a big editor like default 3DView. There is no need to display tool settings and editor properties at same time. I know the reply: "An editor with 2 columns opened is cluttered." As is nobody never changes settings in Properties Column and only use Toolshelf or F6 panel would be suppresed by that. Toolshelf would probably be useless when Pie Menus would have been generalized to everything. Imho, adding a pinned floating panel to the already existing 2 columns would made a worst cluterred UI. Ideal solution would be to have an UI of regions that adapts itself to vertical column or horizontal small bands and detachable regions, dockable tabs. But it would require icons for all tools and autozooming to display all settings correctly. If there is a return of floating panels, I prefer that it would not be one per tab. But preferably, an automatic resized version of current columns.

Takanu commented

2015-02-15 19:21:09 +01:00

Added subscriber: @Takanu

Aaron Carlisle commented

2016-09-04 03:51:57 +02:00

Added subscriber: @Blendify

Julian Eisel commented

2016-12-21 00:20:02 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2016-12-21 00:20:02 +01:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2016-12-21 00:20:02 +01:00

Julian Eisel self-assigned this 2016-12-21 00:20:02 +01:00

Julian Eisel commented

2016-12-21 00:20:02 +01:00

During the 2.8 UI workshop we agreed on adding a global top-bar that would contain the tool settings (similar to what's been proposed here). We'll probably also split the settings into basic and advanced settings (with a 'more' button opening a popup), to save space and to not make the user worry about unnecessary options.
More info: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Top_Bar

Closing this task as resolved. We'll open separate tasks for the final top-bar design. Thanks all!

During the 2.8 UI workshop we agreed on adding a global top-bar that would contain the tool settings (similar to what's been proposed here). We'll probably also split the settings into basic and advanced settings (with a 'more' button opening a popup), to save space and to not make the user worry about unnecessary options. More info: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Top_Bar Closing this task as resolved. We'll open separate tasks for the final top-bar design. Thanks all!

Sign in to join this conversation.