I always will defend the back of the tool option to N.-shelf panel, Like you can see in my sculpt proposal. Allowing the user to have the tool panel inside viewport and in the left or right side.
The topbar is a good place to put some few options, main options an allow to the user change it without the T-shelf or tools panels in properties editor.
Even for non-cintiq users, it’s more efficient to have the tools and the settings on the right, trust me.
Also, Blender should ship with layout variations, not just workspaces (which are terrible btw), so new users could see the possibilities.
If users have the possibility to change it, they will do.
In my case, like all programs that I have seen in 25 years working with PCs have the tools in the left or top, and properties in right or bottom… I preffer to keep the classic estructure.
I’ve expanded my reply in the previous post but I want to add:
The top bar is not a good place for a few reasons:
The format means having to use drop down menus which increase clicks
Different tools have different number of settings and eventually as blender grows this will become a kitchen sink mess or be incomplete. It’s not a long term solution.
It’s a top bar so it could have any window underneath. You won’t want tool settings there while coding or doing compositing. It’s not universal.
It’s far away from the working area which is usually the middle of the screen. The eye doesn’t go there unless on purpose and so it’s hard to tell which option is activated while working.
It’s not a common pattern of UI which means people don’t have an instinctive understanding of it.
Yes, it’s true. Even so, it seems to me as if in the case of the sculpt you often ended up wasting time looking for the panel, extending the one you needed at that moment…
I don’t think the Topbar is currently seen as a place to put all the options of the active tool. Simply as a direct access.
Yes, it’s true, that’s why I add my proposal in the editors who need it, only.
Yes, it’s also true, although it’s also true that practically all the programs put there the properties of the tool and it’s a standard. Anyway, having a topbar doesn’t prevent having a popup on top of the mouse calling it with a key.
I don’t agree, almost anyone who uses any software knows that this bar is usually used for tools or tool options. The weird thing is actually to see it where it is in blender2.8
Anyway, we’re taking the conversation to a point where I don’t want to take it. Because I just want to propose how to fix the topbar and not enter into a full debate about all the interface and other improvements it might need. I prefer to just talk about having to exist a topbar this is a better solution than the current one. And if in the future it is possible to implement an even better solution, welcome.
Mainly because I don’t want to scare the developers into thinking that they should change all that when none of it is necessary. With a very simple change, to put the topbar in a new header, almost all the current problems of the topbar are fixed. Can proposals be presented to improve the workflow? Yes, of course, and I’m doing it in other proposals as you can see, but I do not want to mix them with each other
Exactly.
That’s why, regarding topbars, I will only support proposals like this one:
Clean, clutter free and future proof. Tools settings belongs in the properties editor.
It seems like BF will learn it the hard way, when the topbar will be crowded as hell, with no more space left to put things. 
You seem to be missing one important thing. There are tools with only one option, or even no settings at all, and other tools with a lot of settings.
I have checked all the current active tools and even the longest ones enter in this design in a 1080p screen.
You have something like this:
And you do not have enough space to show even the most basic settings, like the “Brush” and “Stroke” options. If we talk about the popovers, then of course we can put any number of options in just one popover.
And here is an example of how header will look with a different tool selected and if we switch to the “object mode”; with a lot of unused space.
In the same way that in a vertical panel without collapsing you can’t show all the options either, I don’t see any difference. Let’s remember that all those options entered in several tabs of the T-shelf and not completely.
The only difference is that popover access is faster, direct and takes up less screen space.
For example, in my actual laptop, with panels, I only can see one panel at same time
Even if i halve the size of the panel
I see a big problem with the Popovers, you do not see what settings you have now. The Popovers work well for view settings, because you will always see their effect in the viewport. For tools like brushes, it’s much more important to see the current settings, especially the ones you’re constantly changing. The panels can be rearranged and kept constantly open the ones that are important to you now. Also a side panel can be quickly opened and closed with hotkeys.
These stats are pretty biased, methinks.
Though I see where you’re coming from (and agree to some extent in certain cases), you seem to be quite dismissive of any tweaks to your design. In fact, if there is a single thing you can point out that’s negative in other users’ tweaks/advice/recommendations, you focus 100% on that negative thing while ignoring anything positive and dismissing their ideas entirely rather than discussing their potential merits as well (and their possibility to be integrated into your own design.)
This is not a collaborative discussion – This is the tyranny of an idea trying to maintain its dominance.
That being said – maybe this discussion can be more collaborative going forward?
Also, I agree, but this is exactly why I suggested the hybrid approach (see right: pretend those are brush settings):
You can have stuff always displaying (such as the Vertex groups and Shape keys) when the accordion menus are fully-opened, but you can have those same menus be temporary popups as well (when pressing the dropdown icon just beside the arrow).
I don’t think so. In reality I didn’t like the topbar but I’m trying to keep the idea to make the proposal confortable for developers and designers.
And also that many of the ideas are not about this proposal to turn the topar into a header if not other interface proposals. That is a bigger debate that we have had on many occasions.
And as you can see in my proposal I keep asking for the return of the T-shelf to be able to have that on screen for those who need it. But I don’t consider it necessary all the time.
In Zbrush is similar, All options are not visible by default in Zbrush.
For anyone else interested (a clearer definition exists in the PaperCuts thread):
Again, visual-distinctiveness and also organization-according-to-functional-themes (i.e. form follows function) is really key here.
To be fair – because I didn’t use custom controls for Scenes/RenderLayers – I did actually fail at completely eliminating Button Soup™ here:
This rationale is exactly why Button Soup™ has always been so prevalent in Blender.
I could cram all the buttons in the interface in a single panel, like so:
But it doesn’t “work”.
That bottom bar, for example, in the screenshot above – Can you generally tell (in less than 1 second) what their basic functions are? Nobody could – and that has nothing to do with not knowing the program. It has everything to do with the fact that none of the icons have any visually-identifiable relationship to one another, grouping or otherwise.
The tool properties “popup” is no more “annoying” than pressing the “T” or “N” key to slide out a tool or property panel.
Not really a fair argument there. 
On that point, I’ll definitely agree with you.
This was just a rough, quick and dirty mockup to articulate some ideas I’ve been having for the Blender interface for quite some time.
I will rethink the tool properties, but I don’t see any issues with the other parts, save for two (which I will address in my next iteration.)
I’m really open to input though. So please blast away.
Currently we have everything together and is not a button soup, with a few improvements the problem would be even smaller. In addition that the real problem of blender with the button soup is not the header, is all that around this.
I can hardly say that this is a button soup.
I don’t think it has anything to do with what we’re talking about. In my proposal I have included all the properties of tools in the “topbar”. In addition, they are delimited by the own positioning in the bar. It can be improved but it is already quite clear. Can be placed some separator, reorder some element … but in general is more than functional and understandable.
But as I say, could try other combinations
On the contrary, there are quite a few differences. The T or N panel are relatively unobtrusive and do not invade the work area, they delimit it. The panel that you propose if it invades the work area unnecessarily, in addition to needing to resize each tool, would be much more intrusive and annoying And what is the solution to that? Basically give it a whole row to place the options there. That is, the same as in my proposal.
If we go back to the suggestion in the first post where you mixed/rearranged the settings from the editor header and the tool settings, this version is absolutely not acceptable because it will not allow you to hide second editor header.
The only possible solution is an additional, optional second header with tool settings, for those who like a double header.
If we talk about the return of the T-shelf, it is an obvious necessity, and it does not even need to be discussed. How exactly will look and work this panel is already offtopic.
And I see no reason to completely remove the current Top Bar, this is a good place for example for the render button and the render engine indicator that many users ask for.
Why not?.. … …,…
Because the settings are mixed. If you hide one header with the tool settings for example, you need to move the other settings from that header to another. That is, you need to have two versions of the layouts of each header.
I dont understand why
I ask Pablo about the topbar yesterday, I agree with this idea to put the topbar in the n panel
