Top Bar Design #50845

New Issue

Paweł Łyczkowski · 2017-03-03T15:37:45+01:00

2017-03-03 15:37:45 +01:00

Initial Proposal: https://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Top_Bar_Reshuffle
2.8 Workshop Writeup: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Global_Bars
Patches: D2758, #39835, D2451

Description:

The top bar would be a global area at the top of each window (except of temporary windows like User Preferences). The size is fixed, although it should be possible to hide it. Actually what’s being referred to as the top bar consists out of two (sub-)bars. The following lists what each of them could contain:

First bar:
Global menus: File, Window, Help
Menu to choose scene for the current window.
Tabs for workspaces
Add New Workspace button:
Opens a list of default workspaces (this way we can ship Blender with pre-configured workspaces for common workflows, without cluttering the UI with workspaces the user doesn’t need), and the general all-purpose workspace.
Second bar:
Settings of the last executed operator
These should be split into basic and advanced settings.
Buttons for operator options during modal operators (more info)
E.g while using the knife tool it would show checkboxes to enable/disable midpoint snap, angle constraints, cut through, etc.
Menu to choose the active render layer of the workspace (for this design).
Menu to choose the active mode of the workspace.
Menu to choose the active screen layout of the workspace.
Search button to search operators and properties (improved version of current spacebar search).
The search results depend a lot on the context (like the editor and the mode the user is in), but since the search bar should give access to all tools, we need to deal with these context issues somehow. There are some ideas for this but we need to shape them further.

In order to save vertical space, we’ll likely get rid of window decorations. Such as Chrome (screenshot below), Photoshop, or many others.

Current design:

(subject to change, check comments)

Initial Proposal: https://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Top_Bar_Reshuffle 2.8 Workshop Writeup: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Global_Bars Patches: [D2758](https://archive.blender.org/developer/D2758), #39835, [D2451](https://archive.blender.org/developer/D2451) Description: The top bar would be a global area at the top of each window (except of temporary windows like User Preferences). The size is fixed, although it should be possible to hide it. Actually what’s being referred to as the top bar consists out of two (sub-)bars. The following lists what each of them could contain: **First bar:** Global menus: File, Window, Help Menu to choose scene for the current window. Tabs for workspaces Add New Workspace button: Opens a list of default workspaces (this way we can ship Blender with pre-configured workspaces for common workflows, without cluttering the UI with workspaces the user doesn’t need), and the general all-purpose workspace. **Second bar:** Settings of the last executed operator These should be split into basic and advanced settings. Buttons for operator options during modal operators (more info) E.g while using the knife tool it would show checkboxes to enable/disable midpoint snap, angle constraints, cut through, etc. Menu to choose the active render layer of the workspace (for this design). Menu to choose the active mode of the workspace. Menu to choose the active screen layout of the workspace. Search button to search operators and properties (improved version of current spacebar search). The search results depend a lot on the context (like the editor and the mode the user is in), but since the search bar should give access to all tools, we need to deal with these context issues somehow. There are some ideas for this but we need to shape them further. In order to save vertical space, we’ll likely get rid of window decorations. Such as Chrome (screenshot below), Photoshop, or many others. **Current design:** ![shot_170320_124640.png](https://archive.blender.org/developer/F516421/shot_170320_124640.png) *(subject to change, check comments)*

Paweł Łyczkowski self-assigned this 2017-03-03 15:37:45 +01:00

Paweł Łyczkowski commented

2017-03-03 15:37:45 +01:00

Changed status to: 'Open'

Paweł Łyczkowski commented

2017-03-03 15:37:45 +01:00

Added subscribers: @PawelLyczkowski-1, @JulianEisel, @dfelinto, @MikePan, @pablovazquez, @sebastian_k, @JonathanWilliamson

Paweł Łyczkowski commented

2017-03-03 15:38:51 +01:00

Current design:

Current design: ![shot_170303_152121.png](https://archive.blender.org/developer/F501292/shot_170303_152121.png)

Diego Gangl commented

2017-03-03 15:52:02 +01:00

Added subscriber: @Januz

Duarte Farrajota Ramos commented

2017-03-04 07:13:35 +01:00

Added subscriber: @DuarteRamos

Bartosz Moniewski commented

2017-03-06 02:28:51 +01:00

Added subscriber: @BartekMoniewski

Bartosz Moniewski commented

2017-03-06 02:28:51 +01:00

I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go?

Everything else looks very nice and promising.

I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go? Everything else looks very nice and promising.

Diego Gangl commented

2017-03-06 16:44:42 +01:00

I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go?

Solid question. Photoshop (and others) keep opened files in tabs, so they put that information there.

About the scene input: it looks smaller than it is now. And the one we have now only shows only about ~18 chars. Maybe it can be expanded to take a bit more space?

Maybe it can be made to take a certain percentage of space, so if the window is maximized or there are less workspace tabs we can use that space for the scene selector.

The search input could also be a button, since the search op has an input built in the popup.

Another possible idea: move the +andx buttons into the selection popup.

Glad to see this coming together!

> I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go? Solid question. Photoshop (and others) keep opened files in tabs, so they put that information there. About the scene input: it looks smaller than it is now. And the one we have now only shows only about ~18 chars. Maybe it can be expanded to take a bit more space? Maybe it can be made to take a certain percentage of space, so if the window is maximized or there are less workspace tabs we can use that space for the scene selector. The search input could also be a button, since the search op has an input built in the popup. Another possible idea: move the **+**and**x** buttons into the selection popup. Glad to see this coming together!

Julian Eisel commented

2017-03-06 17:00:36 +01:00

In #50845#421146, @BartekMoniewski wrote:
I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go?

We planned to move this kind of info to the status-bar, which will also be a global area, this time at the bottom of the screen. See https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Status_Bar.

In #50845#421234, @Januz wrote:
About the scene input: it looks smaller than it is now. And the one we have now only shows only about ~18 chars. Maybe it can be expanded to take a bit more space?

Maybe it can be made to take a certain percentage of space, so if the window is maximized or there are less workspace tabs we can use that space for the scene selector.

The mockup is really just a sketch, I wouldn't take the spacing of elements that serious. We can of course use more width for the button or even make the width calculation smarter.

Another possible idea: move the +andx buttons into the selection popup.

I've talked with users about this before, but they were a bit wary because of the additional click it would need to add or remove a scene/layout/whatever. TBH I think it's worth it considering the saved space though.

> In #50845#421146, @BartekMoniewski wrote: > I don't think fusing OS title bar with our top-bar is good idea. Lack of blend filepath and save status would be a significant drawback. Where that will go? We planned to move this kind of info to the status-bar, which will also be a global area, this time at the bottom of the screen. See https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Status_Bar. > In #50845#421234, @Januz wrote: > About the scene input: it looks smaller than it is now. And the one we have now only shows only about ~18 chars. Maybe it can be expanded to take a bit more space? > > Maybe it can be made to take a certain percentage of space, so if the window is maximized or there are less workspace tabs we can use that space for the scene selector. The mockup is really just a sketch, I wouldn't take the spacing of elements that serious. We can of course use more width for the button or even make the width calculation smarter. > Another possible idea: move the **+**and**x** buttons into the selection popup. I've talked with users about this before, but they were a bit wary because of the additional click it would need to add or remove a scene/layout/whatever. TBH I think it's worth it considering the saved space though.

Paweł Łyczkowski commented

2017-03-07 10:16:20 +01:00

Another possible idea: move the +andx buttons into the selection popup.

I've talked with users about this before, but they were a bit wary because of the additional click it would need to add or remove a scene/layout/whatever. TBH I think it's worth it considering the saved space though.

I'm less concerned about additional click and more about discoverability.

>> Another possible idea: move the **+**and**x** buttons into the selection popup. > I've talked with users about this before, but they were a bit wary because of the additional click it would need to add or remove a scene/layout/whatever. TBH I think it's worth it considering the saved space though. I'm less concerned about additional click and more about discoverability.

Duarte Farrajota Ramos commented

2017-03-07 17:35:00 +01:00

From a user point of view I would not mind tucking them away into the popup at all, in fact I would encourage it.
I don't mind the additional clicks required, adding or removing Scenes/Layouts/Workspaces should not be that common task that it requires being always visible, I would value much more the saved space and cleaner UI. It would also add the benefit of allowing removing items other the just the current one.

Besides, I have found myself unintentionally removing layouts and scenes more often than I'd like to admit with the current setup. Having the remove button so prominent and without a prompt is especially concerning since removing a layout for example is not undooable currently.

From a user point of view I would not mind tucking them away into the popup at all, in fact I would encourage it. I don't mind the additional clicks required, adding or removing Scenes/Layouts/Workspaces should not be that common task that it requires being always visible, I would value much more the saved space and cleaner UI. It would also add the benefit of allowing removing items other the just the current one. Besides, I have found myself unintentionally removing layouts and scenes more often than I'd like to admit with the current setup. Having the remove button so prominent and without a prompt is especially concerning since removing a layout for example is not undooable currently.

Diego Gangl commented

2017-03-08 14:18:49 +01:00

Adding and removing scenes is not a frequent action, while changing them is. An extra click for these actions isn't going to slow down the workflow, while having less clutter and more space for names would benefit the UI.

As for discoverability, the first place a user would click to do anything related to a scene is the scenes popup. The buttons would be there to be found.

Adding and removing scenes is not a frequent action, while changing them is. An extra click for these actions isn't going to slow down the workflow, while having less clutter and more space for names would benefit the UI. As for discoverability, the first place a user would click to do anything related to a scene is the scenes popup. The buttons would be there to be found.

Julian Eisel commented

2017-03-08 14:38:14 +01:00

We've just discussed the idea of moving the '+' and 'x' icons into the menu here in the Bender Institute, and we agreed this is probably a good thing to do. The 'x' would always and only be visible for the active item of the menu, also adding feedback for what the active item is. Pablo is planning to do some mockups for 2.8 related things, he'll also incorporate this idea.

Paweł Łyczkowski commented

2017-03-11 11:31:22 +01:00

Ok, I'll update the mockup (ETA 7 days since I'm away).

Ray Mairlot commented

2017-03-14 16:05:45 +01:00

Added subscriber: @RayMairlot

Paweł Łyczkowski commented

2017-03-20 12:47:55 +01:00

Update:

Update: ![shot_170320_124640.png](https://archive.blender.org/developer/F516419/shot_170320_124640.png)

Leandro Cavalheiro commented

2017-03-22 15:56:56 +01:00

Added subscriber: @leandro_cavalheiro

Jonathan Lampel commented

2017-03-23 02:46:07 +01:00

Added subscriber: @JonathanLampel-4

michael knubben commented

2017-03-24 09:44:57 +01:00

Added subscriber: @michaelknubben

Matjaž Lamut commented

2017-03-26 13:39:55 +02:00

Added subscriber: @lamoot

Matjaž Lamut commented

2017-03-26 13:39:55 +02:00

Add and remove buttons in the menu look good, but I'd ask about those extra buttons for fake user and the number of users of the datablock. What will happen with F and 5 button on the attached screenshot? Are they even relevant with the upcoming changes to how datablocks are managed in Blender?

Add and remove buttons in the menu look good, but I'd ask about those extra buttons for fake user and the number of users of the datablock. What will happen with **F** and **5** button on the attached screenshot? Are they even relevant with the upcoming changes to how datablocks are managed in Blender? ![menu_datablock_users.png](https://archive.blender.org/developer/F523676/menu_datablock_users.png)

Dalai Felinto commented

2017-03-26 16:06:54 +02:00

@PawelLyczkowski-1 "Window specific above the line, Workspace specific below this line", I though the "current operator" was global, not per-workspace. yet it's below the line

Paweł Łyczkowski commented

2017-03-27 12:43:13 +02:00

@lamoot Workspaces, Screen Layouts and Scenes do not have users. I guess Render Layer will have them (multiple Workspaces can use a single render Layer) yeah - I'll add that to the mockup.

@dfelinto If it's 5 minutes to make it per workspace, please do : ) But I'm guessing it's not, then just ignore the above/below line concept, it's nice for clarity but not that necessary.

@lamoot Workspaces, Screen Layouts and Scenes do not have users. I guess Render Layer will have them (multiple Workspaces can use a single render Layer) yeah - I'll add that to the mockup. @dfelinto If it's 5 minutes to make it per workspace, please do : ) But I'm guessing it's not, then just ignore the above/below line concept, it's nice for clarity but not that necessary.

Diego Gangl commented

2017-03-27 17:46:19 +02:00

How would vector properties (x,y,z) look in the bar?

Also, what do you think about letting operators register their own dropdowns (like the "more" button)? I think it could help organize settings better. The more button could still be auto-added when there isn't enough space for all settings.

How would vector properties (x,y,z) look in the bar? Also, what do you think about letting operators register their own dropdowns (like the "more" button)? I think it could help organize settings better. The more button could still be auto-added when there isn't enough space for all settings.

Diego Gangl commented

2017-04-26 15:03:45 +02:00

Another question about the design: where would the info/error messages go?

Paweł Łyczkowski commented

2017-04-27 12:32:12 +02:00

In #50845#424905, @Januz wrote:
How would vector properties (x,y,z) look in the bar?

Vector properties would look like currently in the redo panel, only one per line and limited width.

Also, what do you think about letting operators register their own dropdowns (like the "more" button)? I think it could help organize settings better. The more button could still be auto-added when there isn't enough space for all settings.

Can't custom dropdowns/popups be added already to redo panel? If not, then sure, that would be good to have.

Another question about the design: where would the info/error messages go?

That would be the planned Status Bar. You can read about it more here: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup

> In #50845#424905, @Januz wrote: > How would vector properties (x,y,z) look in the bar? Vector properties would look like currently in the redo panel, only one per line and limited width. > Also, what do you think about letting operators register their own dropdowns (like the "more" button)? I think it could help organize settings better. The more button could still be auto-added when there isn't enough space for all settings. Can't custom dropdowns/popups be added already to redo panel? If not, then sure, that would be good to have. >Another question about the design: where would the info/error messages go? That would be the planned Status Bar. You can read about it more here: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup

Diego Gangl commented

2017-04-28 03:05:28 +02:00

Another question about the design: where would the info/error messages go?

Ah didn't catch the status bar. That's the perfect solution.

Can't custom dropdowns/popups be added already to redo panel? If not, then sure, that would be good to have.

You can make enums into dropdowns and call menus, but not dropdowns with custom layouts like in the mockup.

> Another question about the design: where would the info/error messages go? Ah didn't catch the status bar. That's the perfect solution. > Can't custom dropdowns/popups be added already to redo panel? If not, then sure, that would be good to have. You can make enums into dropdowns and call menus, but not dropdowns with custom layouts like in the mockup.

voyager25 commented

2017-06-21 21:06:50 +02:00

Added subscriber: @voyager25

Satish Goda commented

2017-07-18 11:25:55 +02:00

Added subscriber: @satishgoda1

michael knubben commented

2017-08-07 17:44:36 +02:00

There has been talk of removing the x and + next to scene/screen data blocks, and moving it to a context menu, or inside of the scene/screen browser. Has there been a definitive decision made on this?
I'm all in favour, for visual clarity and usability (not being able to delete something that can't be undone so easily!), and just curious to see where we stand on that.

There has been talk of removing the x and + next to scene/screen data blocks, and moving it to a context menu, or inside of the scene/screen browser. Has there been a definitive decision made on this? I'm all in favour, for visual clarity and usability (not being able to delete something that can't be undone so easily!), and just curious to see where we stand on that.

Duarte Farrajota Ramos commented

2017-08-07 19:15:41 +02:00

I'd vote for tucking it away in the right-click menu too. Less visual clutter, no accidental deletions, and it could help make the pulldown menus more visually consistent.

I'll also mention here what I mentioned at D2758 #64985.
As it currently stands, the menus are organized in a way that reflects what is a per-window setting and what is a per-workspace setting, which makes all sense from a more technical point of view and perfectly reflects the inner workings of Blender.

I was wondering if it wouldn't be better instead to represent it as a sort of a breadcrumb-like bar, that better reflects a more hierarchical file structure closer to how we tend to mentally organize a scene, with logical larger containers above smaller ones like say:
Scene Selector Pulldown Menu > Layers Pulldown Menu > Interaction Mode Pulldown Menu > Operator % Tool properties at the lower bar, and
And on the top header next to the tabs if possible keep only the ones that may not fit into the same hierarchy like Render Engine selection and Screen Layout which are transversal to all others.

Which would you find more "intuitive"?

I'd vote for tucking it away in the right-click menu too. Less visual clutter, no accidental deletions, and it could help make the pulldown menus more visually consistent. I'll also mention here what I mentioned at [D2758](https://archive.blender.org/developer/D2758)#64985. As it currently stands, the menus are organized in a way that reflects what is a per-window setting and what is a per-workspace setting, which makes all sense from a more technical point of view and perfectly reflects the inner workings of Blender. I was wondering if it wouldn't be better instead to represent it as a sort of a breadcrumb-like bar, that better reflects a more hierarchical file structure closer to how we tend to mentally organize a scene, with logical larger containers above smaller ones like say: *Scene Selector* Pulldown Menu > *Layers* Pulldown Menu > *Interaction Mode* Pulldown Menu > Operator % Tool properties at the lower bar, and And on the top header next to the tabs if possible keep only the ones that may not fit into the same hierarchy like *Render Engine* selection and *Screen Layout* which are transversal to all others. Which would you find more "intuitive"?

xan2622 commented

2017-09-23 17:29:01 +02:00

Added subscriber: @xan2622

xan2622 commented

2017-09-23 17:29:01 +02:00

In #50845#421443, @DuarteRamos wrote:
From a user point of view I would not mind tucking them away into the popup at all, in fact I would encourage it.
I don't mind the additional clicks required, adding or removing Scenes/Layouts/Workspaces should not be that common task that it requires being always visible, I would value much more the saved space and cleaner UI. It would also add the benefit of allowing removing items other the just the current one.

Besides, I have found myself unintentionally removing layouts and scenes more often than I'd like to admit with the current setup. Having the remove button so prominent and without a prompt is especially concerning since removing a layout for example is not undooable currently.

Hello.

I think that the Workspaces & Scene Layouts drop-downs should not necessary be that visible. They take a lot of unnecessary space on the bar, especially for users who still work on 1024x768 or 1366x768 resolutions. IMO, a simple button would be enough.

Here is a mockup:

> In #50845#421443, @DuarteRamos wrote: > From a user point of view I would not mind tucking them away into the popup at all, in fact I would encourage it. > I don't mind the additional clicks required, adding or removing Scenes/Layouts/Workspaces should not be that common task that it requires being always visible, I would value much more the saved space and cleaner UI. It would also add the benefit of allowing removing items other the just the current one. > > Besides, I have found myself unintentionally removing layouts and scenes more often than I'd like to admit with the current setup. Having the remove button so prominent and without a prompt is especially concerning since removing a layout for example is not undooable currently. Hello. I think that the Workspaces & Scene Layouts drop-downs should not necessary be that visible. They take a lot of unnecessary space on the bar, especially for users who still work on 1024x768 or 1366x768 resolutions. IMO, a simple button would be enough. Here is a mockup: ![Sans titre-1.png](https://archive.blender.org/developer/F858523/Sans_titre-1.png)

xan2622 commented

2017-09-23 17:37:53 +02:00

I have also noticed color inconsistency between some search fields:

I suggest to use the same background-color for all search fields (the light color from the "Open File" window makes more sense, even if I agree, the dark color is nice here).

Also, the magnifier icon is misplaced.

I have also noticed color inconsistency between some search fields: ![1_blender_search_fields.png](https://archive.blender.org/developer/F858535/1_blender_search_fields.png) I suggest to use the same background-color for all search fields (the light color from the "Open File" window makes more sense, even if I agree, the dark color is nice here). ![3_blender_search_fields.png](https://archive.blender.org/developer/F858537/3_blender_search_fields.png) Also, the magnifier icon is misplaced. ![4_blender_search_icons_misplaced.png](https://archive.blender.org/developer/F858540/4_blender_search_icons_misplaced.png)

Duarte Farrajota Ramos commented

2017-09-23 19:05:03 +02:00

In #50845#462044, @xan2622 wrote:
a simple button would be enough.

I like that, maybe the tooltip while hovering the icon could show the name of the current layout (if those don't go away), so one doesn't necessarily have to open the menu.

> In #50845#462044, @xan2622 wrote: > a simple button would be enough. I like that, maybe the tooltip while hovering the icon could show the name of the current layout (if those don't go away), so one doesn't necessarily have to open the menu.

xan2622 commented

2017-09-23 22:33:19 +02:00

Btw, now that there is a drop-down button to manage workspaces and another one for screen layouts, I think that the later is no longer needed.
After all, workspaces already feature an embeded screen layout. The user can simply create a clone of the current workspace if he/she wants an alternative layout.

I don't know, maybe I am just thinking out loud but after testing the latest blender-2.80-f2ea8e2-win64.zip daily build, I haven't really found the need to create other screen layouts (especially because workspaces also do the job).

Btw, now that there is a drop-down button to manage workspaces and another one for screen layouts, I think that the later is no longer needed. After all, workspaces already feature an embeded screen layout. The user can simply create a clone of the current workspace if he/she wants an alternative layout. I don't know, maybe I am just thinking out loud but after testing the latest blender-2.80-f2ea8e2-win64.zip daily build, I haven't really found the need to create other screen layouts (especially because workspaces also do the job).

Duarte Farrajota Ramos commented

2017-09-24 02:14:42 +02:00

In #50845#462076, @xan2622 wrote:
The user can simply create a clone of the current workspace if he/she wants an alternative layout.
I haven't really found the need to create other screen layouts (especially because workspaces also do the job).

I have also voiced this concern before, but I don't think the devs agree.

Blender is often criticized for being too complex, and I think this is a great opportunity to simplify, workspaces and layouts is confusing , it just feels redundant and overkill. I don't feel there is any need to keep both around seeing as workspaces can play all the roles of layouts and more.

They are datablocks and can easily be appended and/or cloned then modified with as many differing layouts as desired, so as far as I understood there is nothing that couldn't be achieved with workspaces alone.

> In #50845#462076, @xan2622 wrote: > The user can simply create a clone of the current workspace if he/she wants an alternative layout. > I haven't really found the need to create other screen layouts (especially because workspaces also do the job). I have also voiced this concern before, but I don't think the devs agree. Blender is often criticized for being too complex, and I think this is a great opportunity to simplify, workspaces **and** layouts is confusing , it just feels redundant and overkill. I don't feel there is any need to keep both around seeing as workspaces can play all the roles of layouts and more. They are datablocks and can easily be appended and/or cloned then modified with as many differing layouts as desired, so as far as I understood there is nothing that couldn't be achieved with workspaces alone.

Dalai Felinto commented

2017-10-05 16:02:52 +02:00

In #50845#462076, @xan2622 wrote:
The user can simply create a clone of the current workspace if he/she wants an alternative layout.

That would mean working in two windows with the same workspace would not be possible.

> In #50845#462076, @xan2622 wrote: > The user can simply create a clone of the current workspace if he/she wants an alternative layout. That would mean working in two windows with the same workspace would not be possible.

ronan ducluzeau commented

2017-10-05 18:08:40 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2017-10-05 18:08:40 +02:00

Maybe screen-layouts should be renamed window-layouts to avoïd confusion.
Reference to screen comes a time when multiple windows were not supported.

But now, a screen layout is limited to a window.

Maybe screen-layouts should be renamed window-layouts to avoïd confusion. Reference to screen comes a time when multiple windows were not supported. But now, a screen layout is limited to a window.

Julian Eisel commented

2017-10-05 19:45:20 +02:00

I definitely see the points regarding screen-layouts being redundant, I wouldn't say I disagree completely. I don't fully agree either though, I still think there are good reasons to keep them. In any case, they should be exposed differently than they are now, or not at all even.

First off, screen-layouts have a drastically different role in 2.8 than before. They used to be more like UI presets for various tasks, which is what workspaces do now. In 2.8, they should be nothing but mere layouts for areas (areas are the subwindows containing the editors).
We had the following ideals in mind for screen-layouts:

It shouldn't matter which editors the layout contains. For this, idea was to introduce editor tabs through which users can add multiple editors to an area and switch easily.
There shouldn't be a need for layout names. Instead of selecting a layout by name, users should select them visually. Hence we added layout previews.
So again, screen-layouts are going to be something different in 2.8. Just mere layouts.

(BTW, all of that is mentioned in the 2.8 UI workshop writeup .)

That said, of course it's still possible that screen-layouts within workspaces are redundant.
Here are the main points that speak for having multiple screen-layouts within workspaces:

Multi-window support: we want to allow having a single workspace active in multiple windows. Multiple windows can't show the same screen-layout though (couple of reasons). So to allow having the same workspace active in multiple windows, the workspace needs to contain multiple layouts. (Dalai referred to this already)
Workspaces are a higher level concept than screen-layouts. Users may need different layouts while they work on the same task. E.g. texturing and material editing may need different layouts, while both are part of the "Shading" task.
Workspaces should not be abused for layout switching. Idea of workspaces is to switch tasks (say from modelling to rigging), not layouts.

We could ignore #2 and #3, and just not expose the screen-layouts in the UI.
My suggestion would be to keep them exposed for now though, but only show the small button to spawn the menu. Most users probably won't really notice it using this visual trick, but it's still available for those who use it (see Lock to Scene button). The name button should disappear (no layout names!), the "+" and "x" button should be moved into the popup menu. Let's see how that works out first, and then decide if we want to hide screen-layout buttons.

Also note that we'd eventually like to support hiding buttons . Combined with the template system, templates for beginners could just hide the screen-layout buttons.

I definitely see the points regarding screen-layouts being redundant, I wouldn't say I disagree completely. I don't fully agree either though, I still think there are good reasons to keep them. In any case, they should be exposed differently than they are now, or not at all even. ---- First off, screen-layouts have a drastically different role in 2.8 than before. They used to be more like UI presets for various tasks, which is what workspaces do now. In 2.8, they should be nothing but mere **layouts for areas** (areas are the subwindows containing the editors). We had the following ideals in mind for screen-layouts: * It shouldn't matter which editors the layout contains. For this, idea was to introduce editor tabs through which users can add multiple editors to an area and switch easily. * There shouldn't be a need for layout names. Instead of selecting a layout by name, users should select them visually. Hence we added layout previews. So again, screen-layouts are going to be something different in 2.8. Just mere layouts. (BTW, all of that is mentioned in the [2.8 UI workshop writeup ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Screen_Layouts).) ---- That said, of course it's still possible that screen-layouts within workspaces are redundant. Here are the main points that speak for having multiple screen-layouts within workspaces: 1. Multi-window support: we want to allow having a single workspace active in multiple windows. Multiple windows can't show the same screen-layout though (couple of reasons). So to allow having the same workspace active in multiple windows, the workspace needs to contain multiple layouts. (Dalai referred to this already) 2. Workspaces are a higher level concept than screen-layouts. Users may need different layouts while they work on the same task. E.g. texturing and material editing may need different layouts, while both are part of the "Shading" task. 3. Workspaces should **not** be abused for layout switching. Idea of workspaces is to switch tasks (say from modelling to rigging), not layouts. We could ignore #2 and #3, and just not expose the screen-layouts in the UI. **My suggestion would be to keep them exposed for now though, but only show the small button to spawn the menu**. Most users probably won't really notice it using this visual trick, but it's still available for those who use it (see [Lock to Scene ](https://docs.blender.org/manual/en/dev/editors/3dview/introduction.html#header) button). The name button should disappear (no layout names!), the "+" and "x" button should be moved into the popup menu. Let's see how that works out first, and then decide if we want to hide screen-layout buttons. Also note that we'd eventually like to [support hiding buttons ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Editor_customization). Combined with the template system, templates for beginners could just hide the screen-layout buttons.

Julian Eisel commented

2017-10-05 19:49:21 +02:00

In #50845#464320, @zeauro wrote:
Maybe screen-layouts should be renamed window-layouts to avoïd confusion.
Reference to screen comes a time when multiple windows were not supported.

But now, a screen layout is limited to a window.

Window-layout sounds more like the alignment of multiple windows :) I don't think that's any less confusing. But really, I think screen-layout is pretty fine, it's a standard name. It's definitely one of the less confusing parts from all of this.

> In #50845#464320, @zeauro wrote: > Maybe screen-layouts should be renamed window-layouts to avoïd confusion. > Reference to screen comes a time when multiple windows were not supported. > > But now, a screen layout is limited to a window. Window-layout sounds more like the alignment of multiple windows :) I don't think that's any less confusing. But really, I think screen-layout is pretty fine, it's a standard name. It's definitely one of the less confusing parts from all of this.

Duarte Farrajota Ramos commented

2017-10-06 00:01:28 +02:00

Hum I see now, I do have a multi-monitor setup and make heavy use of multiple layouts for each monitor window, hand't though of that.
If that is the only use then I agree with Julian, maybe they could just be mostly hidden from the user and handled automagically by Blender in the background.

I like were this is going, nice to see things slowly shaping up for 2.8. You devs are awesome, keep up the excellent work. :)

Hum I see now, I do have a multi-monitor setup and make heavy use of multiple layouts for each monitor window, hand't though of that. If that is the only use then I agree with Julian, maybe they could just be mostly hidden from the user and handled automagically by Blender in the background. I like were this is going, nice to see things slowly shaping up for 2.8. You devs are awesome, keep up the excellent work. :)

Julian Eisel commented

2017-10-23 23:50:25 +02:00

So the current top-bar implementation (see D2758) is far enough to care for some design details. I opened a separate task for currently open questions, #53139.

Please help us finding answers on these. Especially agreement from the UI Team is important.

So the current top-bar implementation (see [D2758](https://archive.blender.org/developer/D2758)) is far enough to care for some design details. I opened a separate task for currently open questions, #53139. Please help us finding answers on these. Especially agreement from the UI Team is important.

Pierre Schiller commented

2017-10-25 03:21:53 +02:00

Added subscriber: @PierreSchiller

Pierre Schiller commented

2017-10-25 03:21:53 +02:00

Just out of the blue, innocent question here.... Why don´t we have floating constant windows showing all these at a time and then pop-out of the layout? Why don´t we have floating windows with parameters, again?
Thanks.

Just out of the blue, innocent question here.... Why don´t we have floating constant windows showing all these at a time and then pop-out of the layout? Why don´t we have floating windows with parameters, again? Thanks.

Duarte Farrajota Ramos commented

2017-10-25 04:04:52 +02:00

I have mentioned it before

In D2758 #64985, @DuarteRamos wrote:
Would also love if you brought back the old behavior of popping by default the operator properties pop-up directly in the 3D View, like in the old days of pre-2.49.

Would love the old 2.49 behavior of having operators pop out a non blocking floating panel with all operator properties by default just like the current F6 panel.
I just find it so much more convenient to just have all properties directly right there over the 3D View, without having to change focus to other parts of the UI, or permanently stealing away screen real estate. But it seems devs have different plans.

I have mentioned it before > In [D2758](https://archive.blender.org/developer/D2758)#64985, @DuarteRamos wrote: > Would also love if you brought back the old behavior of popping by default the operator properties pop-up directly in the 3D View, like in the old days of pre-2.49. Would love the old 2.49 behavior of having operators pop out a non blocking floating panel with all operator properties by default just like the current F6 panel. I just find it so much more convenient to just have all properties directly right there over the 3D View, without having to change focus to other parts of the UI, or permanently stealing away screen real estate. But it seems devs have different plans.

Brecht Van Lommel commented

2017-10-25 04:06:40 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-10-25 04:06:40 +02:00

@PierreSchiller, we insist on staying on topic in design tasks like this, you'll find plenty of discussion on the floating windows topic with a Google search.

Brecht Van Lommel commented

2017-10-25 04:17:25 +02:00

In #50845#467316, @DuarteRamos wrote:
Would love the old 2.49 behavior of having operators pop out a non blocking floating panel with all operator properties by default just like the current F6 panel.

There were no operators or operator properties in 2.49, I think you're confusing it with view or transform properties that were in floating panels in 2.49.

> In #50845#467316, @DuarteRamos wrote: > Would love the old 2.49 behavior of having operators pop out a non blocking floating panel with all operator properties by default just like the current F6 panel. There were no operators or operator properties in 2.49, I think you're confusing it with view or transform properties that were in floating panels in 2.49.

Duarte Farrajota Ramos commented

2017-10-25 04:28:13 +02:00

Hum my memory might have been a little fuzzy on that, but if I recall correctly some operators (like Add>Cylinder) had some form of primitive "on-canvas properties pop up" though not all of them, and and they had no interactive preview.

Hum my memory might have been a little fuzzy on that, but if I recall correctly some operators (like Add>Cylinder) had some form of primitive "on-canvas properties pop up" though not all of them, and and they had no interactive preview. ![DBO_2.49Operator.gif](https://archive.blender.org/developer/F1064559/DBO_2.49Operator.gif)

Aaron Carlisle commented

2017-10-25 04:51:09 +02:00

Added subscriber: @Blendify

Aaron Carlisle commented

2017-10-25 04:51:09 +02:00

Side note, but related, I think it would be valuable to have a userpref option to toggle between using the "Toolbar" setting or a popup based system by default. But when one is disabled the other can be accessed through F6. For example, I can choose by default to have the operator open a popup by default but after starting the operator I can press F6 which will close the pop-up and open the "Toolbar" settings.

This can give more flexibility to artist so they can choose how to use their screen space.

Side note, but related, I think it would be valuable to have a userpref option to toggle between using the "Toolbar" setting or a popup based system by default. But when one is disabled the other can be accessed through F6. For example, I can choose by default to have the operator open a popup by default but after starting the operator I can press F6 which will close the pop-up and open the "Toolbar" settings. This can give more flexibility to artist so they can choose how to use their screen space.

Paweł Łyczkowski commented

2017-11-08 12:17:21 +01:00

Added subscriber: @wevon-2

Paweł Łyczkowski commented

2017-11-08 12:17:21 +01:00

@wevon-2 asked this in the patch task, moving it here:

In D2758 #68546, @wevon-2 wrote:
Surely developers see it clearer than me, but I personally find several blind spots in the design of the top bar. Sorry in advance if I'm confused.

I throw some doubts and reflections:

What attributes will show the top bar, the tools, or the last action performed?
The actions that take the position of the cursor when executed as move, extrude or bevel ... do not allow to comfortably access the toolbar during its execution to modify a parameter. There will be a problem similar to what we now have when the action is launched from the tool panel.
The tools are adjusted before or while they are used, while the parameters of the action are adjusted after applying the action. I understand that a temporary modal tool, show its attributes in the toolbar hiding those of the last action, but if the tool is permanent, as the active tools of the latest versions of Blender, I believe that generates conflicts.

Are paint and sculpting paintbrushes considered tools or modes?
In my opinion they are tools with many attributes, and these atributes should be in the top bar. Having six atributes in the top bar and the rest in the floating menu of advanced options I see it a bit ridiculous for some tools. For this reason in the image below I show the options distributed in panels inside the topbar.

What will be shown in the Left Side Panel, once we have the top bar?
Actually it shows a mixture of buttons to execute actions, properties of tools and options of tools, depending on the mode and the shelf in which we are.

Mode is global or by area?
If I have not misunderstood, in version 2.8 the mode will be global, and I can not imagine it without the existence of an active area, since it often works with more than one area on the screen.

What attributes will show the top bar, the tools, or the last action performed?

If a tool is active - tool settings. If an operator (action) was fired - operator settings.

The actions that take the position of the cursor when executed as move, extrude or bevel ... do not allow to comfortably access the toolbar during its execution to modify a parameter. There will be a problem similar to what we now have when the action is launched from the tool panel.

That's the design of these operators. You will be able to tweak their settings after applying them. Some might get a tool mode, and as such will be more GUI-button-friendly. See https://developer.blender.org/T53047 for more info.

I understand that a temporary modal tool, show its attributes in the toolbar hiding those of the last action, but if the tool is permanent, as the active tools of the latest versions of Blender, I believe that generates conflicts.

Can you describe those conflicts?

Are paint and sculpting paintbrushes considered tools or modes?
In my opinion they are tools with many attributes, and these atributes should be in the top bar. Having six atributes in the top bar and the rest in the floating menu of advanced options I see it a bit ridiculous for some tools. For this reason in the image below I show the options distributed in panels inside the topbar.

@JulianEisel Your opinion on that?

What will be shown in the Left Side Panel, once we have the top bar?

It will generally be the same as now, minus the Last Operator Settings panel, and stuff that would migrate to the topbar if we do something like in your mockup.

Mode is global or by area?
If I have not misunderstood, in version 2.8 the mode will be global, and I can not imagine it without the existence of an active area, since it often works with more than one area on the screen.

Mode will be global, yes. It was per-object before as far as I understand it, not per-area, so no active area is needed.

@wevon-2 asked this in the patch task, moving it here: > In [D2758](https://archive.blender.org/developer/D2758)#68546, @wevon-2 wrote: > Surely developers see it clearer than me, but I personally find several blind spots in the design of the top bar. Sorry in advance if I'm confused. > > I throw some doubts and reflections: > > 1. What attributes will show the top bar, the tools, or the last action performed? > The actions that take the position of the cursor when executed as move, extrude or bevel ... do not allow to comfortably access the toolbar during its execution to modify a parameter. There will be a problem similar to what we now have when the action is launched from the tool panel. > The tools are adjusted before or while they are used, while the parameters of the action are adjusted after applying the action. I understand that a temporary modal tool, show its attributes in the toolbar hiding those of the last action, but if the tool is permanent, as the active tools of the latest versions of Blender, I believe that generates conflicts. > 2. Are paint and sculpting paintbrushes considered tools or modes? > In my opinion they are tools with many attributes, and these atributes should be in the top bar. Having six atributes in the top bar and the rest in the floating menu of advanced options I see it a bit ridiculous for some tools. For this reason in the image below I show the options distributed in panels inside the topbar. > 3. What will be shown in the Left Side Panel, once we have the top bar? > Actually it shows a mixture of buttons to execute actions, properties of tools and options of tools, depending on the mode and the shelf in which we are. > 4. Mode is global or by area? > If I have not misunderstood, in version 2.8 the mode will be global, and I can not imagine it without the existence of an active area, since it often works with more than one area on the screen. > ![TopBar.jpg](https://archive.blender.org/developer/F1103190/TopBar.jpg) > 1. What attributes will show the top bar, the tools, or the last action performed? If a tool is active - tool settings. If an operator (action) was fired - operator settings. > The actions that take the position of the cursor when executed as move, extrude or bevel ... do not allow to comfortably access the toolbar during its execution to modify a parameter. There will be a problem similar to what we now have when the action is launched from the tool panel. That's the design of these operators. You will be able to tweak their settings after applying them. Some might get a tool mode, and as such will be more GUI-button-friendly. See https://developer.blender.org/T53047 for more info. > I understand that a temporary modal tool, show its attributes in the toolbar hiding those of the last action, but if the tool is permanent, as the active tools of the latest versions of Blender, I believe that generates conflicts. Can you describe those conflicts? > 2. Are paint and sculpting paintbrushes considered tools or modes? > In my opinion they are tools with many attributes, and these atributes should be in the top bar. Having six atributes in the top bar and the rest in the floating menu of advanced options I see it a bit ridiculous for some tools. For this reason in the image below I show the options distributed in panels inside the topbar. > ![TopBar.jpg](https://archive.blender.org/developer/F1106773/TopBar.jpg) @JulianEisel Your opinion on that? > 3. What will be shown in the Left Side Panel, once we have the top bar? It will generally be the same as now, minus the Last Operator Settings panel, and stuff that would migrate to the topbar if we do something like in your mockup. > 4. Mode is global or by area? > If I have not misunderstood, in version 2.8 the mode will be global, and I can not imagine it without the existence of an active area, since it often works with more than one area on the screen. Mode will be global, yes. It was per-object before as far as I understand it, not per-area, so no active area is needed.

Albert commented

2017-11-11 18:28:34 +01:00

Thank you for clarifying some questions Paweł Łyczkowski.

Can you describe those conflicts?

For now there are no conflictors because the modal tools are adjusted during their execution by pressing keys, the brushes work using other modes, and the new active tool modes do not request previous adjustments to their use. So you can see the operator settings at any time and temporarily, when you activate a modal tool, you visualize the parameters of the modal tool, and when you accept or cancel the tool changes, you see the operator settings again.

The problems can arrive at the moment you want to configure a tool before its application, to be able to adjust the parameters comfortably, without using hotkeys (like the current Blender brushes or the tools of Maya). It will not be possible to see the pre-parameters and the post-parameters from the same bar, unless there is a double bar, or parameters are explicitly called.

Currently in Blender these pre-parameters are found in the Header (transformation coordinates, pivot, proportionality, snaps), in the menu bar (AutoMerge editing), and in the Tool Shelf options tab (symmetry, UV preservation) . In Maya most of these parameters are within the options of the transformation tool, and are adjusted before use.

If the tools are concrete (Ex: Extrude Individual, Circle Select, Merge at Center), and not general as (Ex: Extrude, Select, Merge), and the Header or some other site may contain the options that the tool needs before its execution, I see no problem. If not, I think you would need a button or a keyboard shortcut to swich between the Operator Settings if you want to make some adjustment on the action done, and come back to the tool options again.

I hope to explain myself well and be wrong, although everything has a solution.

Thank you for clarifying some questions Paweł Łyczkowski. > Can you describe those conflicts? For now there are no conflictors because the modal tools are adjusted during their execution by pressing keys, the brushes work using other modes, and the new active tool modes do not request previous adjustments to their use. So you can see the operator settings at any time and temporarily, when you activate a modal tool, you visualize the parameters of the modal tool, and when you accept or cancel the tool changes, you see the operator settings again. The problems can arrive at the moment you want to configure a tool before its application, to be able to adjust the parameters comfortably, without using hotkeys (like the current Blender brushes or the tools of Maya). It will not be possible to see the pre-parameters and the post-parameters from the same bar, unless there is a double bar, or parameters are explicitly called. Currently in Blender these pre-parameters are found in the Header (transformation coordinates, pivot, proportionality, snaps), in the menu bar (AutoMerge editing), and in the Tool Shelf options tab (symmetry, UV preservation) . In Maya most of these parameters are within the options of the transformation tool, and are adjusted before use. If the tools are concrete (Ex: Extrude Individual, Circle Select, Merge at Center), and not general as (Ex: Extrude, Select, Merge), and the Header or some other site may contain the options that the tool needs before its execution, I see no problem. If not, I think you would need a button or a keyboard shortcut to swich between the Operator Settings if you want to make some adjustment on the action done, and come back to the tool options again. I hope to explain myself well and be wrong, although everything has a solution.

Paweł Łyczkowski commented

2017-11-14 11:26:54 +01:00

The problems can arrive at the moment you want to configure a tool before its application

You confuse a tool with an operator. When you activate a tool (via keystroke or GUI button), it's settings appear in the top bar, and you can change them at any point between tool operations (for instance between separate cuts with the Knife tool).
Keyboard fired operators will stay shortcut and mouse driven, for quick use, and the top bar will work like the current Last Operator panel in the Toolshelf, for final tweaks after using the operator.
The idea is also to convert some operator only functionality into tool functionality, as described here: https://developer.blender.org/T53047
There is no plan as far as I know concerning the pivot, proportional editing and snapping changes.

>The problems can arrive at the moment you want to configure a tool before its application You confuse a tool with an operator. When you activate a tool (via keystroke or GUI button), it's settings appear in the top bar, and you can change them at any point between tool operations (for instance between separate cuts with the Knife tool). Keyboard fired operators will stay shortcut and mouse driven, for quick use, and the top bar will work like the current Last Operator panel in the Toolshelf, for final tweaks after using the operator. The idea is also to convert some operator only functionality into tool functionality, as described here: https://developer.blender.org/T53047 There is no plan as far as I know concerning the pivot, proportional editing and snapping changes.

Paweł Łyczkowski commented

2017-11-16 14:03:43 +01:00

So I'd really appreciate if you could leave some quick & honest feedback based on your testing.

Sure. Please be aware that I can be biased with feedback, since I helped with the design.

Here is the build that I tested (It's Win 64): https://www.dropbox.com/s/srbye0n89zi8bpk/Blender%20Topbar%20Build.zip?dl=0

A screenshot of it for reference:

The feedback:

First and foremost - the topbar feels quite natural. I was worried that settings changing and flickering in and out in there will be distracting or annoying - this turns out not to be a problem. The whole GUI responds to actions anyway - buttons appear and disappear, windows content change in response to user actions all the time, so the topbar behaves just like the rest of the interface in this regard and does not stand out.
Next, the location of the settings promotes their usage much more than the Last Operator panel. I was surprised to find that the settings help even in pretty basic operations. For instance the user can eyeball a translate operation, and then refine the values quickly in the topbar.
I was worried that empty space appearing from time to time will look awkward, but it's not that big of a deal. The header for instance is often mostly empty as well, and Julian managed to keep the topbar pretty tight vertically, so there is not as much empty space as I feared:

The 'More' popup is what I called a 'Quick Settings Popup' in the past, meaning it allows to change a couple of settings, and goes away when the cursor leaves it (or I guess when the user clicks outside of it on a touch interface), and it works as well as I hoped.

There are some problems, for instance not all operators work well with the topbar out of the box, so additional work has to be done there (Loop Cut And Slide is an example). Many have many settings that are currently displayed needlessly as basic settings. An example would be Proportional Editing settings in transform operations. Some operators may have to be recoded - for instance Extrude is currently coded as two operation: something like Inset with 0 thickness and then Translate - this way we get the Translate settings in the topbar after an Extrude - it could work better as a single operation, where the Extrude Amount is the main setting (might be also friendlier to ctrl-z).

A benefit that I didn't predict is that the last operator displayed in the top bar gives a hint on what action the user did last - so it can be checked easily. This helps with stray key presses or clicks, or just when one forgets at what point he is with one's 3d work. The Toolshelf Last Operator panel did not do that as well due to it's obscure location.

The one big advantage that I see is that exposing operator settings is a big help with discoverability. Toolshelf Last Operator panel is in a pretty obscure place - the Toolshelf is not always visible, the settings are crammed there, the 3d View where it's located is not always big enough to display it properly or even added to the window at all, and settings from all editors are displayed in that panel, not only the 3d View ones. It's potential to boost discoverability is squandered a lot.

Take a look at this screenshot on the other hand. This is what appears when after using the Unwrap operator:

One can instantly learn that there are different algorithms that Unwrap can use, that one can change the Margin of islands, and that there are different toggles that do different things. And this works for all such operators.

The current implementation of tool settings (ex. Knife) are very awkward and have low discoverability. This is not in the build yet, but I'm pretty certain that having proper GUI buttons in a well exposed place, that remember their settings and clearly display if they are on or off has better ergonomics than a line of text where all these options are hidden with multiple additional keyboard shortcuts with which these settings are controlled:

And the main reasons for the topbar mentioned by Brecht still stand - operator settings for all editors go to the Last Operator panel, so it's not really logical for it to be in a Toolshelf in the 3d View. A global top bar cleans this up.

>So I'd really appreciate if you could leave some quick & honest feedback based on your testing. Sure. Please be aware that I can be biased with feedback, since I helped with the design. Here is the build that I tested (It's Win 64): https://www.dropbox.com/s/srbye0n89zi8bpk/Blender%20Topbar%20Build.zip?dl=0 A screenshot of it for reference: ![shot_171116_125028.png](https://archive.blender.org/developer/F1143292/shot_171116_125028.png) The feedback: First and foremost - the topbar feels quite natural. I was worried that settings changing and flickering in and out in there will be distracting or annoying - this turns out not to be a problem. The whole GUI responds to actions anyway - buttons appear and disappear, windows content change in response to user actions all the time, so the topbar behaves just like the rest of the interface in this regard and does not stand out. Next, the location of the settings promotes their usage much more than the Last Operator panel. I was surprised to find that the settings help even in pretty basic operations. For instance the user can eyeball a translate operation, and then refine the values quickly in the topbar. I was worried that empty space appearing from time to time will look awkward, but it's not that big of a deal. The header for instance is often mostly empty as well, and Julian managed to keep the topbar pretty tight vertically, so there is not as much empty space as I feared: ![shot_171116_131614.png](https://archive.blender.org/developer/F1143332/shot_171116_131614.png) The 'More' popup is what I called a 'Quick Settings Popup' in the past, meaning it allows to change a couple of settings, and goes away when the cursor leaves it (or I guess when the user clicks outside of it on a touch interface), and it works as well as I hoped. There are some problems, for instance not all operators work well with the topbar out of the box, so additional work has to be done there (Loop Cut And Slide is an example). Many have many settings that are currently displayed needlessly as basic settings. An example would be Proportional Editing settings in transform operations. Some operators may have to be recoded - for instance Extrude is currently coded as two operation: something like Inset with 0 thickness and then Translate - this way we get the Translate settings in the topbar after an Extrude - it could work better as a single operation, where the Extrude Amount is the main setting (might be also friendlier to ctrl-z). A benefit that I didn't predict is that the last operator displayed in the top bar gives a hint on what action the user did last - so it can be checked easily. This helps with stray key presses or clicks, or just when one forgets at what point he is with one's 3d work. The Toolshelf Last Operator panel did not do that as well due to it's obscure location. The one big advantage that I see is that exposing operator settings is a big help with discoverability. Toolshelf Last Operator panel is in a pretty obscure place - the Toolshelf is not always visible, the settings are crammed there, the 3d View where it's located is not always big enough to display it properly or even added to the window at all, and settings from all editors are displayed in that panel, not only the 3d View ones. It's potential to boost discoverability is squandered a lot. Take a look at this screenshot on the other hand. This is what appears when after using the Unwrap operator: ![shot_171116_134537.png](https://archive.blender.org/developer/F1143363/shot_171116_134537.png) One can instantly learn that there are different algorithms that Unwrap can use, that one can change the Margin of islands, and that there are different toggles that do different things. And this works for all such operators. The current implementation of tool settings (ex. Knife) are very awkward and have low discoverability. This is not in the build yet, but I'm pretty certain that having proper GUI buttons in a well exposed place, that remember their settings and clearly display if they are on or off has better ergonomics than a line of text where all these options are hidden with multiple additional keyboard shortcuts with which these settings are controlled: ![shot_171116_135652.png](https://archive.blender.org/developer/F1143373/shot_171116_135652.png) And the main reasons for the topbar mentioned by Brecht still stand - operator settings for all editors go to the Last Operator panel, so it's not really logical for it to be in a Toolshelf in the 3d View. A global top bar cleans this up.

Leroy commented

2017-11-22 03:36:08 +01:00

Added subscriber: @Leroy-Xie

Leroy commented

2017-11-22 03:36:08 +01:00

I really don't like the top bar design, , the F6 panel is much more useful and practicability, maybe it's good for the beginner, more obvious.

For me, more operation base the shortcut keys, I really don't want to move the mouse cursor over all screen, for example in the new design, if I want do some tools setting, I must move the mouse to the topbar, if I can't find, I must to click the "more" button, than floating a panel, than I move the mouse cursor to the floating panel, the cursor move move move and move, and the setting bar is small, from left to the right, and long, move your focus left to right. So the parameter setting in one panel is much better, in comparison the F6 panel is more nice, even the the option panel in the tool shift(T panel);

BTW, in the new photoshop, they are much more focus on the properties panel, it's much fast and efficient than the setting bar, not need left to right, not need move your mouse from here to here, all in one space, direct and quick setup.

when I told my friend the new design about the topbar, almost all people feel disgusted with it, even joking that designers have Autodesk spies, hahah : )

I really don't like the top bar design, , the F6 panel is much more useful and practicability, maybe it's good for the beginner, more obvious. For me, more operation base the shortcut keys, I really don't want to move the mouse cursor over all screen, for example in the new design, if I want do some tools setting, I must move the mouse to the topbar, if I can't find, I must to click the "more" button, than floating a panel, than I move the mouse cursor to the floating panel, the cursor move move move and move, and the setting bar is small, from left to the right, and long, move your focus left to right. So the parameter setting in one panel is much better, in comparison the F6 panel is more nice, even the the option panel in the tool shift(T panel); BTW, in the new photoshop, they are much more focus on the properties panel, it's much fast and efficient than the setting bar, not need left to right, not need move your mouse from here to here, all in one space, direct and quick setup. when I told my friend the new design about the topbar, almost all people feel disgusted with it, even joking that designers have Autodesk spies, hahah : )

Julien Kaspar commented

2018-09-21 19:05:13 +02:00

Added subscriber: @JulienKaspar

Julien Kaspar commented

2018-09-22 10:43:05 +02:00

So far working with the current UI for a few months now I have some more notes, mainly about the sculpting & paint modes. It's about some information that can be revealed and made accessible by default without taking up too much additional space.
Here's a mockup:

My main problems currently are:

If the Toolbar is set to a grid view, then the name of the active tool is completely hidden. Adding it to the icon fixes this and keep the user from guessing the tool based on just the icon. (I know, it's the wrong name in the mockup, ignore that :D)
Decreasing the width of the size & radius sliders and adding a pressure sensitivity option to each can be a great and simple addition since these can and will be toggled quite often during the day.
At some point the Dyntopo tab got an update by adding a checkbox to it's side, always making it clear if it was turned on or off. This is essential for some settings.
Add at the very least a checkbox for the texture & texture mask tabs to make it clear if one is used or to turn it off without removing the selected texture.
Add an icon to the stroke tab that shows if it's set to dots, anchor, space, etc.
Add an icon to the curve tab if a certain preset is active. Maybe even a direct representation of how the custom curve looks like. This one is less essential though but can be a useful addition.
Add at the very least an active icon for both symmetry & lock settings if either are active. This could look similar to the object visibility/selectability popup in the 3D view header but could also be more precise and show the color of the axis/axes that are currently used for symmetry and/or locking.

There are also these buttons that are too hidden or completely missing.

The Automerge button should definitely make a return. When modeling I want to quickly be able to switch this on and off or at least be easily aware if it's active or not. This setting like dyntopo can seriously destroy you models in certain cases with the difference that you usually notice this one too late.
Putting toggles for Automerge Editing and also X-Mirror next to the Mesh Options tab in Edit Mode should be added in my opinion.
I hope that viewport render & animation will also be added again since these are not available at the moment anymore.

But there are also a couple settings that should not be hidden within a popup sometimes when working but I don't think these can be previewed properly in the top bar.
For example the color palettes and weight presets. These should be visible at all times when needed.

They could be viewed from the Tool Settings tab in the properties window instead but I'm not a huge fan of that. But that's a different topic.

I don't know how much of this was already planned in one form or another but this is at least my feedback on the top bar.

So far working with the current UI for a few months now I have some more notes, mainly about the sculpting & paint modes. It's about some information that can be revealed and made accessible by default without taking up too much additional space. Here's a mockup: ![mockup_top_bar.png](https://archive.blender.org/developer/F4783984/mockup_top_bar.png) My main problems currently are: - If the Toolbar is set to a grid view, then the name of the active tool is completely hidden. Adding it to the icon fixes this and keep the user from guessing the tool based on just the icon. (I know, it's the wrong name in the mockup, ignore that :D) - Decreasing the width of the size & radius sliders and adding a pressure sensitivity option to each can be a great and simple addition since these can and will be toggled quite often during the day. At some point the Dyntopo tab got an update by adding a checkbox to it's side, always making it clear if it was turned on or off. This is essential for some settings. - Add at the very least a checkbox for the texture & texture mask tabs to make it clear if one is used or to turn it off without removing the selected texture. - Add an icon to the stroke tab that shows if it's set to dots, anchor, space, etc. - Add an icon to the curve tab if a certain preset is active. Maybe even a direct representation of how the custom curve looks like. This one is less essential though but can be a useful addition. - Add at the very least an active icon for both symmetry & lock settings if either are active. This could look similar to the object visibility/selectability popup in the 3D view header but could also be more precise and show the color of the axis/axes that are currently used for symmetry and/or locking. There are also these buttons that are too hidden or completely missing. ![lost_icons.png](https://archive.blender.org/developer/F4783988/lost_icons.png) The Automerge button should definitely make a return. When modeling I want to quickly be able to switch this on and off or at least be easily aware if it's active or not. This setting like dyntopo can seriously destroy you models in certain cases with the difference that you usually notice this one too late. Putting toggles for Automerge Editing and also X-Mirror next to the Mesh Options tab in Edit Mode should be added in my opinion. I hope that viewport render & animation will also be added again since these are not available at the moment anymore. ![mesh_options.png](https://archive.blender.org/developer/F4783993/mesh_options.png) But there are also a couple settings that should not be hidden within a popup sometimes when working but I don't think these can be previewed properly in the top bar. For example the color palettes and weight presets. These should be visible at all times when needed. ![color palette.png](https://archive.blender.org/developer/F4783990/color_palette.png) They could be viewed from the Tool Settings tab in the properties window instead but I'm not a huge fan of that. But that's a different topic. I don't know how much of this was already planned in one form or another but this is at least my feedback on the top bar.

Lapineige commented

2019-02-13 10:04:32 +01:00

Added subscriber: @Lapineige

Julian Eisel commented

2020-06-26 19:02:46 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Julian Eisel closed this issue

2020-06-26 19:02:46 +02:00

Julian Eisel commented

2020-06-26 19:02:46 +02:00

I think we can close this task at this point. There's a general design in place. It does have some weaknesses, e.g. we need to improve tool settings placement (see https://devtalk.blender.org/t/tool-settings-are-on-too-many-places).
Improving this is to a degree general development. We can open new tasks as needed.

I think we can close this task at this point. There's a general design in place. It does have some weaknesses, e.g. we need to improve tool settings placement (see https://devtalk.blender.org/t/tool-settings-are-on-too-many-places). Improving this is to a degree general development. We can open new tasks as needed.

Sign in to join this conversation.