Can we go back to the standards now? Clearly this idea of an extra menu didn't work.

@Gavin Scott (Zoot) Couldn't agree more. 🙁

In D4854#111207, @Pablo Vazquez (pablovazquez) wrote:

This solves a number of issues:

In rB688e3fed4c255ddcfe98f08d1004dc2c0abd51ef#230794, @Brecht Van Lommel (brecht) wrote:

How is it more dangerous in Blender than another app, how do separate editors or files make a difference for that?

@Brecht Van Lommel (brecht) You can see in popular apps from adobe, cinema 4d etc, that they have separate editors for things like keymaps etc..
For example, this is photoshop:

A revert function is not popular indeed, and actually is not that useful.
What we need is an option to turn on/off preferences autosaving, and I believe most users will not want to have this enabled by default, because blender preferences is very different from most softwares out there.
In most apps out there, things like keymap settings, addons/plugins, sometimes even themes, they usually have a separate editor each, and you save those settings separately. Usually those things are not part of the main preferences, that's why they can afford to have that preferences autosaving feature, because their preferences is not that complex, which is not the case in blender.
It would be nice if we could save the quick favorites in a separate file, so we could load it everywhere. Some apps gives you a prompt when quitting if you want to save the unsaved keymap changes, blender could do the same.

@William Reynish (billreynish) And what about the playhead text color, is it linked to something else at moment as well? I can't find it.

@William Reynish (billreynish) @Jacques Lucke (JacquesLucke) It seems like this commit broke the theme text color of the vertical numbers and the playhead number text colors.
Before it used to work like this: The vertical and horizontal numbers were linked to the text color property, and the playhead text were linked to the text highlight color property.

@William Reynish (billreynish) My main concern was the vertical numbers moving to the right as well, but I can see that you also got feedback from animators and you agreed to keep it on the left. So all is fine.

The vertical scrollbars in the graph editor etc, are more useful on the left. On the right they will be too far from the "action" zone. I don't think that's a good idea.

Icon outlines would do the trick, I guess.

I like that.

Perhaps the default objects should not be inside a Collection?

Why hide the topbar by default? This makes things difficult for new users.

Great improvement!
I hope you guys don't change it. This is next level of interaction. 👍

In T57727#661048, @Campbell Barton (campbellbarton) wrote:

Discussed w/ @Brecht Van Lommel (brecht) and we agreed to do the following.

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

In T57727#660223, @Campbell Barton (campbellbarton) wrote:

Am not convinced

@Campbell Barton (campbellbarton) Awesome. Thanks.

So If I'm using an active tool that has a custom gizmo like the extrude tool for example, it will override the transform gizmos, right?
Then if I'm running something like the inset tool which doesn't have a custom gizmo, the transform gizmo will show up?
How's the priority of this?

Awesome! I've been waiting for this since the introduction of the selection tools. 👍

@Harley Acheson (harley) Ok, Thanks.

@Harley Acheson (harley) Are those lines themeable?

Yeah. Those changes there destroyed the all thing, We are asking them to revert some of those changes but no luck. See here: https://developer.blender.org/D4529

Alright.
I hope to see something similar for the tools in the context menus in the future, specially for the edit mode tools. 👍

This also affects the tools that are in the right click context menus?
That's the part I'm most interest in. Currently the modal tools that are on the context menus are pretty much unusable, they should be calling the active tools as well.

This seems very useful. 👍

@Brecht Van Lommel (brecht) Ok. I thought it was a bug because in 2.79 it displays correctly.

In D4529#103522, @ronan ducluzeau (zeauro) wrote:

Seriously, that are awful changes.

@Clément Foucault (fclem) @William Reynish (billreynish) Just a quick question.
Why can't blender really highlight only the components (vertex/edges/faces) of the mode selected, without mixing it, like the majority of the 3D apps out there?
Quick example:

Disable "Outline" and this will go away.

Please don't.
Maybe as an option in the preferences to satisfy the Mac users.

In D3594#101059, @Erick Tukuniata (erickblender) wrote: Please provide a build so people can test and give feedback.

In D3594#101016, @Campbell Barton (campbellbarton) wrote:

hold off on this feature until after 2.80 initial release.

Exactly.

Yeah, that can be annoying.

I prefer the current behavior.
Blender preferences is very complex, it makes sense to have a "Save Preferences" button imo.

Turning off region overlap fixes it, yeah.
I think region overlap should be off by default. It's just causing too many problems at this point for no reason.

In T57918#611187, @William Reynish (billreynish) wrote:

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

1. Add Box Select to the Drag Action dropdown inside the transform tools
2. Add some new way to make transform gizmos visible while other tools are active
   
   I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other.
   
   Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion.
   
   We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there.
   
   This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

I guess I'm the only one who thinks this is not an issue.
A tooltip would be more than enough. I mean, there are plenty of apps with similar feature and yet there's nothing fancy happening with their buttons.

In T61480#619361, @Campbell Barton (campbellbarton) wrote:

How would the popup be activated? (what key, which menu)

@Dalai Felinto (dfelinto) Yeah, I know about the alt + h, that's why I said "for the sake of completeness", because if we can ctrl + click to isolate, naturally and intuitively people would expect a similar way of undoing the isolate (ctrl + shift + click).
Anyway, thanks for the quick fix and all the hard work on this.

@Dalai Felinto (dfelinto) This is nice, but for the sake of completeness I guess we would also need something like "ctrl + shift" to go to the previous state, or at least to unhide everything?
And btw, when I alt click, there's no way to go back, clicking/alt clicking again does nothing.

Blender is literally the only 3D/DCC app that starts in windowed mode, and it's truly annoying. So yes, maximized by default please.

Exactly.
If a matcap is looking overexposed or something, it's because it was made to look that way or was just poorly made.
Matcaps are displaying more accurately now, which is great.

Why not display a crosshair cursor like in most sculpting apps (zbrush etc...)?

Great. 👍

In T57918#611187, @William Reynish (billreynish) wrote:

some users would like to be able to do box select while the transform gizmos are visible.

There's this open source online sculpting app https://stephaneginier.com/sculptgl/ which also has this brush cursor feature. Not sure which method it uses but it feels quite nice. Maybe worth take a look?

In D3594#96644, @Julien Kaspar (JulienKaspar) wrote:

@ThinkingPolygons (ThinkingPolygons)

Actually this is nothing, really. Zbrush works pretty much like that, it never was an issue.

I just checked the difference. While the single face normal Blender cursor goes completely crazy on high frequency detail, Zbrush seems to have some sort of averaging on a small scale to prevent that. The cursor rotates only slightly there.

This sort of thing would be pretty distracting while sculpting:

In D3594#96606, @Pablo Dobarro (pablodp606) wrote:

From my experience, I strongly prefer the face normal version.

I tried this feature in the build Pablo Dobarro shared on his twitter page, and I can say that this is already a hundred times better than the current brush cursor, even if it's not 100% accurate. The difference is like night and day. Every digital sculptor would love to have this feature.
Can't it be optional, so those seeking 100% accuracy could turn it off?

Confirmed.
Same with matcaps etc...

Confirmed.

Confirmed.

@Kent Davis (mac4kent) You mean this, right? The popup can't go out of the window/cropped text etc...?

@Brecht Van Lommel (brecht) Thanks for the clarification. But this intended behavior is a little tough to deal with. For example if I want to upgrade my keymap by changing some preference, I'd have to build everything from scratch. Quite painful.

Confirmed.

Are you looking for the keymap section?

Very useful. Can't wait to see it included. 😃

Disable Load UI when opening the blend file.

Looks more like something not yet implemented, than a bug.

I wish the cursor had it's own color setting.

This is a tough one to theme, as it seems like it doesn't have a separate dedicated theme setting.

@Campbell Barton (campbellbarton) It's showing 4 here too.

Ok, I just configured my keymap and did a quick test, and yes, both features are working pretty well together. The click for "cycling" is not that slow either. I can comfortably click to cycle or double click to loop select. So there are no issues at all imo.

@Campbell Barton (campbellbarton) Okay I see. Most 3d softwares have this feature yeah, but usually only for object modes or similar. I never saw this in an edit mesh situation. I'm not even sure if it's that useful in edit mode.
Double click to loop select seems far more handy than this in edit mode tho.
But even in those other apps, this feature always requires you to "click slowly" for it to work, otherwise you'll trigger the double click event.
So I guess both features can still be available in edit mode without conflicting?

Sorry, but what is "selection cycling"?
Is it a very often used feature?
I can say that the double click to loop select made a lot of users happy. If there's a chance to bring this back, I'd go for it.

That's very unfortunate. This was truly a handy feature and standard in most 3D apps. I don't think it's good to have it only for the Emulate 3 Button Mouse feature.
I hope you guys decide to bring that back.

Confirmed.

This is perfect.

How can I even comfortably see a very long file path in the sidebar?
Opening the sidebar/resizing just to see the full file path is just too much work imo.
I'd prefer no change at all, than putting it on the sidebar.

Please, having the file path visible on the screen is important.
If it's not possible to have it at bottom then just move it on the right side of the Run Script button. Having it in the sidebar is not ideal, because you're basically hiding something very important.

In T57857#559319, @Brecht Van Lommel (brecht) wrote: do we show the eye icon in the outliner or not?