My greatest gripe currently is with the position. It is actually tucked to the left, but because the toolbar has variable width, and doesn't always reach the bottom it often looks random and misplaced.

In T57718#551757, @Brecht Van Lommel (brecht) wrote:

Shouldn't it be the other way around, rename the other primitives properties to be "Size"? The Cube or Monkey having a radius is a bit odd.

The floating redo panel could also use some redesign, it currently looks out of place because of the toolbar.
Perhaps centered at the bottom of the viewport, ideally movable/draggable anywhere in the 3D View

Maybe some sort of highlight hover effects encompassing all draggable properties/buttons.

That looks pretty good already, very useful, many thanks.
Only suggestion I can think of is perhaps to draw some sort of local Z axis pointing to the current tilt direction, to make it clearer to the user where it is currently facing.
If possible even two axis one for X and Y. Bonus points if these axis are actually capable of snapping to other geometry, for precise tilting.

This is shaping up to be an excellent upgrade to general usability.
My only concern so far is that I think Select All operator should be mapped to Ctrl + A, in the name of keeping up with "industry standards".
It is the common select all in many applications, and the default behavior in operating systems, like the file manager, lists of items, or text input boxes, among others.

Q: Both of these are incompatible with 3D viewport-specific local view cursor, how to solve? ~ ideasman42

In T54943#541669, @-L0Lock- wrote:

Suggestion: change the default active tool.

Right now it is set on 3D Cursor, which newcomers don't know and may not understand what's happening on the firsts clicks. And even for regular blender users, this isn't the tool you need right away after launching nor that often while working.
I would suggest something more understandable and useful for everyone, such as the Move tool or the Transform tool.

Technically they are handles from the Oxford Dictionary Handle: (Noun) The part by which a thing is held, carried, or controlled. which is what they do after all.
They provide a way to select or manipulate abstract objects that have no real geometry or representation of their own

@Adam Preisler (Alphisto) The hexagonal arrangement was mostly aesthetic, at the end of the day it always works in a radial fashion. Placement could be adjusted if needed, didn't give it much though I was just pointing out the perceived order of entries.

In T56649#537818, @William Reynish (billreynish) wrote:

The only problem with the same key closing the pie, is that we could also use keys to activate pie options while it is open.

In T56881, @William Reynish (billreynish) wrote:

Pie menus could be added more places too - suggestions welcome

In T56702#535852, @William Reynish (billreynish) wrote:

Your suggestion of a 'default tool' should not be necessary. It's essentially the same as enabling a Transform tool and disabling Click Anywhere.

In T56702#535852, @William Reynish (billreynish) wrote:

Alt+LMB for view manipulation works in Blender currently when Emulate 3 Button Mouse is enabled in the Preferences. This is useful for users who don't have a 3-button mouse, and more importantly, many modern mice have unfomfortable scroll wheels that are not nice to click. Alt+LMB has always been an alternative, it just happened to not work for LMB select. We should fix that.

Make sure we always put the Properties on the right for consistency

I like the idea of "multiple splash screens", I find it to be a nice compromise between everyday usability and welcoming new users.

We could even add a dropdown right in the splash screen for this setting.

In T54896#521587, @William Reynish (billreynish) wrote:

In T54896#521545, @Antonio Vazquez (antoniov) wrote:

@William Reynish (billreynish) We still have pending where relocate the old toolbar operators like this:

Any idea?

Yes.

A few suggestions if I may. They make sense for my use cases, but I'm not sure how they alight with the global vision or everyone else's workflow.

Currently in Blender 2.79, under the Circle Select Modal keymap, C key Release event can be set as Confirm, essentially making it only work when it is pressed.

Perhaps the "Mesh Edit Mode" category could be named more generic like "Object Data" or just "Edit Mode" to be more broad and eventually encompass more settings.

I generally like the direction Andrzej Ambroz work is taking, keep up the excellent work.

Without seeing it in action I'm blindly wondering if in the Ctrl+H collection menu regular click shouldn't just toggle layers, and Ctrl+Click would isolate instead.

This is a fantastic improvement, great work.
It would also be useful if Blender could automatically "auto advance" to the next slot upon rendering.

Would it be too much trouble to allow longer collection (or datablock in general) name length?

Not entirely UI related, but do you have any plans to remove Hemi type lamps from the add menu and Blender entirely?
They were only really supported by Blender Internal, the old GLSL viewport and Blender Game Engine, which were all removed.
Cycles never really needed those, and were interpreted as point lamps AFAICT, and with the introduction of EEVEE it seems they are no longer useful.

I believe the space bar, being such a prominent and easy to reach key in most keyboards, should be reserved for something really important and frequently used.
Quite frankly I wouldn't mind at all if it was kept as the current search menu, it is an easy way to reach most operators not immediately available in the UI.

In D3400#79143, @Germano Cavalcante (mano-wii) wrote:

In D3400#79122, @Duarte Farrajota Ramos (duarteframos) wrote:

Some targets are already somewhat confusing (like Closest, which takes the point from the bound box instead of the object).

This is absolutely great, I've been following Germano's work on improving the snap system and it is most welcome improvement. This was probably one of my last remaining gripes with Blender.

The visual feedback of manipulators will make life a lot easier for newcomers and "eyeballed" modeling.

I think this was originally declined by the developers because it tampered too much with the transform code, which was said to be delicate already.
Wondering if something like this could somehow integrate with the new work being done on T54661: Gizmo Design instead.

In T54963#500023, @Ludvik Koutny (rawalanche) wrote:

I agree that consistency is good, but I am not sure there are that many users associating deselection key with modifier key for inverse of the action. My reasoning for this is that Shift key is very commonly used for addition to selection, not only in CG software, but in common mainstream software.

In T54987#501541, @Tomas (Rusculleda) wrote:

Hi! I'd like to point out that the § symbol is absent from many popular keyboard layouts

Not sure if this fits entirely in this task, but since there seem to be changes in the way input values are treated, Would it be very hard to support ignoring leading zeroes?
Currently if one accidentally types 05 or 003 in a value box it fails to set the property, and the input is ignored and reset to previous value.

In T54951#500286, @William Reynish (billreynish) wrote:

The auto-collapse thing also exists, but you have to hold down a modifier key. We could make it more discoverable somehow.

I'm really loving the style and overall design; vertical tabs and search filtering make a lot more sense.

In T54963#499959, @Mantas Kuginis (MantasKuginis) wrote:

In most 3D industry applications, animation packages, even in file managers, LMB click and drag on empty area = initiates Marquee/ Border select.
LMB click and drag on active area = Gives user ability to Move selected items by dragging

Really like the direction this is going. If I may add, I'd like to suggest a consistent use of modifier keys.
Currently in Blender the Alt key has become sort of a "reverse" or "opposite" key for many operators; like H hides Alt+H unhides, P Parents, Alt+P unparents, R Rotates, Alt+R clears rotation etc., you get the idea.

Really like the whole direction this is taking.
One suggestion if I may: If feasible make progress bars bigger, possibly filling the whole available width.
Especially for blocking actions like rendering, or baking simulations, while few other info needs to be displayed.
Or optionally make the progress bar a background thing over which other icons and info are overlayed.

This is looking better and better, 2.8 Outliner is finally going to become what it should have always been, great work!