@Alberto Velázquez (dcvertice) please limit replies to feedback on this diff.

This patch only listens claims and needs of users of modal tools. The users of active tools are relegated, ignored and separated, in one way or another, from the rest of the tool options and users. It is not taking into account their point of view or their future user experience, because currently this user is almost non-existent.

Why can't an active tools user see his tool options in the same bar as other users? For users of Active Tools the pivot, snap, orientation,... are part of the configuration of the active tool. Why should they find their options in a hidden side panel or in a different bar and see the snap, pivot and other options mixed with menus and the viewport shading options? Doesn't make much sense.

I do not see wrong that there is an extended options panels that do not fit in the tool-settings bar. Or for people that preffer to use the old T-shelf workflow. But this proposal breaks the interface logic and coherence.

Basically with this interface active tools users are told that they are required to have an extra bar of options occupying the entire interface, or the entire deployed N-panel, which occupies twice as much. Just because the user of modal tools doesn't want to lose a twenty-fifth of that screen space.

This is the interface that a active tool user must to use

instead of this

Because for some modal users think that this interface is inusable because needs a lot of space.

It doesn't seem fair to me with the users of active tools this approach.

I think there are better solutions that don't go through breaking everything that the tools header gets, like moving the object mode menu to the tool-bar, the components mode, allowing to change the tool-bar background color and allowing to hide the menu header and shading. Which are menus that a user who uses modal controls should rarely use.

@Alberto Velázquez (dcvertice) I don't quite understand what is your argument, this path seems to be about adding an extra option for you to customize the interface either by using the topbar or not, If I get it right this allows you to hide the topbar and use the n-panel instead but doesn't remove the topbar permanently and doesn't relegate active tool users.

//*OFFTOPIC
please dont think in such an separation of users, we all are blender users, I would like to see the unification of active and modal tools I don't know why there must be a distinction between modal and active tools, why not add shortcuts to active tools and effectively replace modal tools with them? It in essence they are the same concept but accessed either by a interface button or a shortcut, if we add an option for making those shortcuts one-time use or sticky tools would in principle simply merge both.
END_OFFTOPIC*//

I like this change a lot, seems like the most mature way to deal with the topbar problem but currently its too hard to hide and unhide the topbar, it should be easier, either by having a shortcut just like N and T bars or by having a toggle somewhere in the viewport header written "Show Tool Settings".

I think my argument is clear. Why can't an active tools user see his tool options in the same bar as other users? Why don't we hide the tools that you and me need in the n-shelf and keep the header only for active tool users?

In D4721#108365, @Alberto Velázquez (dcvertice) wrote:

I think my argument is clear. Why can't an active tools user see his tool options in the same bar as other users?

you can! the point is that in addition to having the topbar now its also available in the N-bar If it annoys you that topbar enabled isn't the default anymore, at least keep in mind that it wasn't removed just like Right click isn't.

In D4721#108365, @Alberto Velázquez (dcvertice) wrote:

Why don't we hide the tools that you and me need in the n-shelf and keep the header only for active tool users?

Why would we hide the tools we need? this doesn't make sense.

In D4721#108366, @Jean Da Costa (jeacom256) wrote:

Why would we hide the tools we need? this doesn't make sense.

Basically you are agreeing with me.

You don't want the tools you use the most hidden in the N panel, but you want the tools that others will use the most hidden in the N panel or in a different header.

If you have the right to have an easy access bar with all the modeling tools you need, all other users also have the same right. And no one has the right and reason to separate the active tool from the rest of the tool options because other users don't want to hide four shading buttons they use once a day. Which are basically useless for any user with more than two months of experience.

This is getting confuse to me.
Anyway the only thing this patch does is moving the topbar to inside the viewport, nothing is really changed from a usage point of view, only that if there are multiple editors with multiple active tools, now each region have its own topbar and even if you hide it you still have access to the same settings in the N-panel isn't that?.

Awesome patch!

In D4721#108378, @Jean Da Costa (jeacom256) wrote:

This is getting confuse to me.
Anyway the only thing this patch does is moving the topbar to inside the viewport, nothing is really changed from a usage point of view, only that if there are multiple editors with multiple active tools, now each region have its own topbar and even if you hide it you still have access to the same settings in the N-panel isn't that?.

No, the topbar inside each area, you have that in master. This patch remove the unique tool settings bar, separate the active tool control, leave the old option of unique global header and duplicate the active tool in n-panel

For users of Active Tools the pivot, snap, orientation,... are part of the configuration of the active tool.

For all users, these settings are fundamentals. They are not just used by active tools. They are used by all tools.

@Alberto Velázquez (dcvertice) , you just want to be able to hide the row of menus, popovers, display modes, etc...
That was not understood by @Campbell Barton (campbellbarton) who thought that collapsing menus would be satisfying . That does not mean there is a league of modal users against you.

You have to admit that your mockup is a little bit weird. A modeler don't necessary care about display modes if he knows about how to jump from wireframe mode to solid mode.
He may not care either of object modes switch or select element mode switch if he knows about Ctrl Tab and 1,2,3 shortcuts.
If you are new to blender and doing everything with a tablet by pressing buttons, you will not hide this row.

A more accessible version of what you are asking for would probably include a minimized switch without names for object modes, select element modes buttons and display mode buttons without 4 popovers.

In D4721#108386, @ronan ducluzeau (zeauro) wrote:

For users of Active Tools the pivot, snap, orientation,... are part of the configuration of the active tool.

For all users, these settings are fundamentals. They are not just used by active tools. They are used by all tools.

That's exactly what I told. That controls are important for all users and must be in same place for all users.

@Alberto Velázquez (dcvertice) , you just want to be able to hide the row of menus, popovers, display modes, etc...
That was not understood by @Campbell Barton (campbellbarton) who thought that collapsing menus would be satisfying . That does not mean there is a league of modal users against you.

I don't think that I told that here, at least it was not my intention. But since I'm not native English, it can be misunderstood. I told that modal users ask for changes that only are good for modal users (I'm only modal user). I'm playing devil's advocate.

It's true that I see that behaviour in devtalk.

You have to admit that your mockup is a little bit weird. A modeler don't necessary care about display modes if he knows about how to jump from wireframe mode to solid mode.

I think that is something that I told a lot of times here and in the proposal thread. Perhaps by trying to keep the proposal small and summarized that became a little more blurred. I also show a example of the way to work.
https://devtalk.blender.org/uploads/default/original/2X/b/b80a83957f74b610b337862e64c10cfdba6e5f62.jpeg

But it's true that for a developer that maybe only see the first message of the thread in detail, don't see the RCS proposal,... the feature is not clear.

He may not care either of object modes switch or select element mode switch if he knows about Ctrl Tab and 1,2,3 shortcuts.
If you are new to blender and doing everything with a tablet by pressing buttons, you will not hide this row.

In my proposal both controls are in the tool-settings bar, and the area type to the menus header. And my logic, although I don't explain it, is that both controls have to do with the tools, especially the components. And in the case of the object mode I also prefer it in the tool-settings bar because it is not something that many people use for hotkey. Besides that it is necessary to have it at sight to know in which mode these.

Also by logic I understand that the common thing will be to want to hide the header bar first, and rarely the toolbar. Instead of now, that user can hide only the toolbar or both headers.

A more accessible version of what you are asking for would probably include a minimized switch without names for object modes, select element modes buttons and display mode buttons without 4 popovers.

The problem with that, was one of my first ideas, is that newbies never will know how to change the mode if you quit the name to the menu. Could work with a bigger button that break theme.

About the shading buttons... I preferred to keep the "Tools Header" and "area options header" concept and I don't like dynamic interfaces. But it's true that it's a option. I simply believe that this way the toolbar can be used more, expand new options currently hidden (such as automerge and mirror) and add new options like those commented on in the proposal (search field or future ideas).

I don't know, on the one hand it gives me the impression that some of the ideas of the proposal were not clear, but on the other hand I think that you have understood everything well.

Well, those tool options are not that frequently used, I kinda like the idea of moving these options to the N-bar because I can hide and show it easily whenever I want without much trouble, as opposite to the topbar that doesn't have a shortcut.
I don't care about wasting viewport space if I can hide what I am not using with one keystroke, the only thing that bothers me for the newbies a bit is that the N-bar is kinda far away from the toolbar, but its kinda cool that we could have all those settings located in one comprehensive and meaningful and hiddable place.

Well, those tool options are not that frequently used

For any option in Blender, you can find a a user saying that is fundamental to his work.
They did not end up in Blender by chance. Somebody need it and asked for it in or added it to Blender.
So, presupposing that some options are more important or more used than other is always misleading.

A pure modeler that never does shading stuff does not use lookdev mode as much as a lighting guy.
And this last one like an animator does not care at all about options of modeling tools.
But they are all using Blender and asking it to display what matters for them and ignore what does not.
Ideally, everything should be hideable and potentially visible at first sight.
Of course, it is not possible to handle everything by default. That is why UI is scripted.

Some people will use menus or switches from headers, others pie-menus and others will prefer rightclick menu.
Some people want a sidebar always open and others prefer to have it always closed.
Those kind of preferences can be relative to their experience, their habits but that may also be related to other things like their equipment (tablet or mouse, big screen or small screen).

The use of small screen is a legitimate motivation to ask for a unique row of header.
And if we can agree on a categorization of 2 rows of an header, there is no reason to presuppose that content of one is more important and should be more shown than content of the other .
In other words, if one row is hideable, the other one should be hideable, too.
The meaning of settings always visible in this proposal, is that header contains in fact 3 or 4 categories of things for only 2 rows.

Well, I didn't get if you agreed to me or not but you seem right.
I personally don't care about the topbar, I don't like it to be honest, I like the idea of having my settings on the N-bar but from what I understand the topbar is only being used for settings of the active tool system, I also don't use active tools, so I never cared about anything but be able to hide the topbar, but if in the future we happen to have other important settings on the topbar, I'm glad to have them duplicated on the N-bar so, I am not forced to unhide it.

Also I know its too late and out of this scope but I cant stop thinking that the right place for the active tool buttons would be the top bar and not the toolbar while the N-bar hold all those settings as its meant for.