If the user wishes to ‘freeze’ the node tree, they can do so by running a ‘Freeze Nodes’ operator, or by going to Edit Mode, which will automatically prompt the user to freeze the mesh.

That doesn't have to be the case, as any operator called from within Edit Mode could add a corresponding node to the tree instead, keeping the process non-destructive. It's also important to be able to access edit mode to just select components (points, faces) to work on, or to simply transform a selection. Such an operation could be stored in a 'transform' node.

In T65426#693928, @William Reynish (billreynish) wrote:

Following your steps, the mirror effect looks normal.
However, if you add more steps, such as rotating the empty, then indeed there seems to be an issue

In T56744#693209, @William Reynish (billreynish) wrote:

@Hadrien Brissaud (hadrien) Hopefully yes, this is an area that can improve - especially with dynamic brush previews.

Is this going to be worked on further or is it considered final ? (brushes as tools, global brush palette)

Pressing F2 could pop up a window with two fields (label & name), auto focusing the label field ?

I agree that having enum items jump positions depending on which one is currently active does not seem desireable (what Brecht says), but I have no experience using this, am only judging from the captures provided above. An indicator however would be most welcome, either in the form of a checkmark or a dot at the rightmost edge of selected enum item, or a different background color.

Nice addition, thanks ! Can't versioning code take care of updating drivers on scalein/scaleout ? Or maybe it's simply possible through python (not familiar with this area).

Also, even for LMB select, we could keep Ctrl-RMB as an alternative way to scrub anywhere. But it’s too hidden to be the only way, and requires using a modifier key.

This is fantastic, mad props. :) Does it also apply to copy rotate constraint ?

That looks very nice, great proposal. Probably out of the scope of this task, a way to set a custom falloff curve would be welcome at some point too.

For the record, it's been swinged at before : https://developer.blender.org/T40059

In D3869#94718, @Campbell Barton (campbellbarton) wrote:

You're valuing perceived consistency above typical workflows and down sides of making users have to re-consider these options when they switch between editing different objects.

2: Select all items in-between when holding shift / select individual items by holding Ctrl.
When holding shift to select multiple items, we can select all the items in between.
Users can then use Ctrl to select individual items without the ones in between.

Alright my bad.

In D4123#93672, @Harley Acheson (harley) wrote:

Perhaps based on the difference between the header width and the totals of all the items’ current widths, so the current amount of empty space on the header.

Could it be handled by the new adaptive layout engine (the one from preferences editor) ?

There could be an auto-hide thingy that shows the button text when it has enough space, and shrinks down to a simple arrow when the viewport is resized ?

Mesh edit mode menus are singular (vertex, edge, face), so maybe have those be singular as well (control point, segment) ?

Very good point. I also use a tablet exclusively (forearm injury prevents me from using a mouse for longer periods of time) and this has been one of my pet peeves. The popovers could also benefit from being scrollable - I am mainly thinking of overlays, as it can quickly get very lengthy, but this is also valid for the new collection visibility popover : I expect with complex scenes it might quickly overflow as well.

I understand that you argue in favor of making more settings available to more brush types - I consider this can only be a good thing ! However I also understood that in your line of thought this brought along the deletion of many brushes from the toolbar/quick-access/whatever because of their similarity to one another. Let me know if I misunderstood. To me, this would be ill-advised because being able to make several very different brush presets from a single brush-type/tool does not justify not making those readily available in the first place.

In T56744#555946, @Julien Kaspar (JulienKaspar) wrote:

I am aware that there are more settings under the hood that make the Tools different but these are very simple and artificial.
You can still make a Clay Strips brush out of a Clay brush. There is not need to make these 2 separate Tools.

Hey, this is obviously going in the right direction, but I would like to add this : having tool presets appear in the viewport toolbar would be fantastic (in a tab, or in a retractable part of the region).

Just want to say this is a fantastic idea !

Just chiming in to suggest making this optional. I really don't want to have to look at this while animating, it looks extremely busy.

Two remarks from reading this discussion :

I hate to nag you guys about this, but seeing as there's work on including pie menus in default 2.8 config -which imho is a good move- it seems the right moment to do so. If there was any chance this could be looked at it would be neat. Let me know if it needs clarification.

In rBbf4ce5755f3699105a1e97793db63f9fc8f7ad9a#184634, @Clément Foucault (fclem) wrote:

In rBbf4ce5755f3699105a1e97793db63f9fc8f7ad9a#184631, @Hadrien Brissaud (hadrien) wrote:

Great ! Is this using merwin's technique ? (suposedly preventing zfighting)

https://youtu.be/MD7MU-UVG2U?t=13m41s

Well I wouldn't call it merwin's technique but yes it's the same idea :)

Great ! Is this using merwin's technique ? (suposedly preventing zfighting)

https://youtu.be/MD7MU-UVG2U?t=13m41s

Ok thanks for the clarification. I am not really convinced this is an improvement over an overlapping toolbar (as with the T region), but let's see it shaping up !

Alright ! Is it meant to stay visible when an editor is maximized ?
How does it know which settings to show if two editors are open side by side ? Or is there only one tool active at a time ?
Is it also meant to host settings for the "simpler" tools like knife, etc (which have only a handful of checkboxes) ?

In T55043#504103, @PawelP (Zuorion) wrote:

In T55043#503960, @Hadrien Brissaud (hadrien) wrote:

It seems like this is essentially moving the T region to the right-hand-side ?

"T" and "N" are (Just press F5 while mouseover panel) and should remain flippable

It seems like this is essentially moving the T region to the right-hand-side ?

Not sure why groups are kept around actually, wouldn't collections completely fill the functionality gap ?
As for the three horizontal lines, don't you think it's really too generic ? As you say, it could evoke stacked layers, or pretty much anything else... additionally it is quite connoted because this design is used more and more on the web and in other programs (Firefox comes to mind), and in those other contexts it usually means "menu" or "more...".

I like the cardboard box one (4 or 5). I also like the first one but the icon for "group" already looks like a group of objects (a sphere and a box) and having a group of three objects as the icon for collections is a bit confusing.
Having all collection-related icons in a different color could also make sense - after all we already have a color code within the outliner : orange (objects), grey (data), blue (modifiers). Why not have them in say, green ? It could also help differentiate at a glance what is a collection and what is an object (color stands out more immediately than shape, I think).

This is really, really great. Do you think it is doable for the graph editor as well ?
https://blender.community/c/rightclickselect/P0bbbc/snap-toggle-in-graph-editor (see mockup)

Small remark : view orbiting does not work very well with "trackball" setting (probably because the grab point is in the viewport corner), maybe this could use turntable orbit regardless of interaction settings, or set the grab point to be the screen center.

Just found this patch pretty much by accident - it would be fantastic to have it sometime in the future, now that the manipulators are on the way.

@Campbell Barton (campbellbarton) what do you mean by "which aren't on the same axis" ? I think simply using a click-and-drag rather than a keystroke is already much easier - this was the rationale behind pie menus iirc : less travel for the keyboard hand (it suddenly strikes me how primitives input devices still are...). I agree that neither this one, nor any other manipulator should be designed without the input of several of the target users.

Some thought on the F-Curve: Key-Frame Manipulator
As an animator (mostly working in Maya for jobs, and Blender for personal stuff, so might lack experience with Blender's animation tools overall) the reasoning behind this manipulator is I find a little difficult to move several keyframes at once, especially when it's on a single axis - shortcut G+X/Y works but it makes editing in the graph tiring when tweaking loads of keyframes - either adjusting values (moving on y) or adjusting timing (moving on x) on an entire shot can feel taxing after a short while. Adjusting a single keyframe is fine with a tablet since middle-clicking during a transform will snap to the closest axis (and you can do that with a tablet pen), but moving several keyframes requires hitting G anyway.
So, a 2d manipulator like the one in the 3d view would be welcome. It doesn't have to look like two perpendicular arrows - it could be a box encompassing the current selection or something different. It should allow for moving independently on a single axis as well as freely on both axes. Maybe it could allow for scaling as well by dragging its corners. If it ends up taking that kind of shape it could get in the way of selection so it's probably important that it stays toggle-able.

I think you missed my post above @Campbell Barton (campbellbarton) because it got buried in a sea of equally awesome suggestions. :) I suggested bbone roll control in the 3dview, and translate manipulator in the graph editor.

For all suggestions that relate to constraints/modifiers : I like the idea, but when is the manipulator displayed / how is it toggled ?

Hi Campbell, hi everybody, here are some of my own ideas.

Not sure if usability feedback is welcome at this point, but this manipulator could use a handle to move plane point on all axes in addition to the circle and arrow. Super cool nonetheless ! :)

Your mockup looks good Alex ! only two remarks :

Thanks a bunch Severin.

@Julian Eisel (Severin) Just a heads up, no pressure, wanting to know if this could possibly be looked into before 2.8 ? I know you guys are pretty busy.

Just a small typo in description text : "Cull objects which are further away from camera than this distance"

For reference, mypaint uses a kind of action (stroke) grouping, defined by the time elapsed between two strokes, could be something to investigate.

Maybe uniform transforms better be offset from the center, which as you said is busy already. I could picture a uniform scale widget like this yellow handle :

Chris, the difficulty is integrating scale with translate and rotate as well. Unless we make it impossible to display all three at once ? but would'nt it be a tad lame ?

Looks great ! Just some remarks :
View axis rotation (white circle) does not interfere with other axes ? (it looks like they have similar radius)
Would the final design of the uv widget include planar transform as well as rotation circle ?

I dig this, thanks for all the work Severin.

I was wrong, for some reason the nvidia driver was not working correctly and Blender was executed with intel igp. So, known issue, I understand. Antonis' message dates back to february, that looks like everyone is too busy to look into this.

I run Blender on a laptop wih an intel igp and an nvidia card (gtx660m) and blender executable is set to run with nvidia card (and it does for sure since I can render with cuda and viewport performance is good).

Got it

Yes, both on Windows and Fedora, release and buildbot.
(Fedora with Wayland if that is relevant)

Still happening for me, both on Windows and Fedora.

Since recent switch from Win7 to Fedora, can confirm this also happens under X session with 2.75a.

My own mistake, please disregard. Sorry for disturbance.

Sorry for confusion, I just meant : latest master does not solve rBcb023ce0fd1a0c.

@Julian Eisel (Severin) the issue I reported still happens on my machine but this one doesn't - I don't encounter any issues when scrolling in userprefs window (opened with ctrl+alt+u)... are these related ?

Actually still hapenning...

Thanks for taking a look Severin. So far as I know using a curve is the only way of making a bunch of objects follow and travel along an arbitrarily shaped path (?). Maybe it would solve the issue to have an additional field inside the follow path constraint where to point at another object/bone from which to derive up and forward axes ? This problem will arise any time someone happens to have a straight curve - I really feel something is broken here. Will keep trying to work around it.

Same when using nurbs curve instead of bézier.

It does the same on Windows build from yesterday (with factory settings). Menu shadow width has to be set to below 4. I can't pinpoint it better than that...

I see - apologies !

Failed twice. It should show now :

Failed to attach example file. Here it is.

Thanks for the clarification Bastien.

In description I wrote frame 6, I meant frame 2.