In D2842#66770, @Dalai Felinto (dfelinto) wrote:

I'm pretty sure we had this discussion before. You want to setup a workspace, and re-use it for different projects. If the render settings are exclusively part of a layer, you cannot open a new file, add one of your pre-defined workspaces, pick a different layer, and start working.

That is totally valid and I never said this shouldn't be possible. The question is just how do we make this possible. And this is where we disagree. We agree on the requirements, we disagree on the specifications.
I don't think moving (mostly duplicating) a bunch of render-settings to the workspace is a good way to solve this.

I'm still strictly against moving any render settings, including the engine, to workspaces.
IMHO this should be our last resort, definitely not our first choice.

With such issues, you can easily check if they are caused by customizations by (temporarily) resetting Blender to factory settings. If you like to do heavy-ish customizations that's something you should keep in mind, it can be really useful.
Regarding the remaining "Restore" items - it's hard to tell what causes this and if this is a bug. It would need further investigation. If this continues to appear, better open a new report.

In T52659#457475, @Dalai Felinto (dfelinto) wrote:

My suggestion instead:

• Add a re-route socket when disconnecting a socket.
• If you draw a re-route socket into an empty socket, you remove the re-route socket, and link the re-route socket input with this new socket.
  
  This way you can still easily disconnect and reconnect sockets in an almost non-destructive way. And it doesn't add any new functionality to Blender, just polish the existent ones.

TBH this sounds like a rather confusing workaround to me :) Imagine a new reroute socket appears each time you disconnect sockets. It would be a confusing surprise to see those reroutes appear out of the blue ("what are these little dots that keep appearing?!") . A different behavior when using knife cutting would be even more confusing. And like Campbell mentioned, you had to remove them all the time.

In general, good suggestion indeed. I see lots of potential here.

Animation nodes show why a color based 'language' has its limits here. The range of colors the human eye/brain can see is simply not enough if much information has to be communicated through colors. From what I know we're talking about more than 60 different node socket types, so a need for 60+ different colors.
Also, when talking about using colors as language, we should always keep in mind that there are color blind people. IMHO something really important to keep in mind.

I'm a bit unsure about the cmake_minimum_required bump to 3.1. Blender itself only requires 2.8. I'd find it weird to have Blender require 2.8 and a module of it 3.1.
I also think most Linux distros only have something older than 3.1 in their default repositories (Debian Jessie repos only have 3.0.2, which is what I'm using here).

I second @Joshua Leung (aligorith)'s words, I had the same thought. I can see two things which would need to be done/looked at:

• Drawing of a 'X' that is easy to catch and looks nicely in place.
• Typically such buttons are in the upper right corner but this space is currently used for build info. Possible Solution: We could move build info to the re-purposed info editor in 2.8? (https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Info_Editor).

In D2758#65044, @Galen Beals (galenb) wrote:

Excellent! Looks really great.

If I may add too: The tabs replicate the function of the layouts menu. It seems like there only needs to me a way to remove layouts and you're good to go with just tabs. couldn't You easily get rid of the layout menu and gain some space?

The tabs actually represent workspaces, which are new in 2.8. They are there for configuring Blender for different workflows within a project (modelling, animating, rendering, compositing, ...). Previously, that kinda was the purpose of screen-layouts, but workspaces go much further than they do.
We figured there is still a need for multiple screen-layouts within those workspaces. So actually, each workspace can contain it's own list of screen-layouts now. That's why there are both, workspace tabs and the screen-layout switch.

In D2758#64985, @Duarte Farrajota Ramos (duarteframos) wrote:

The order of the buttons, pulldown menus, tools etc should try to roughly reflect some sort of hierarchy, like say:
Scene Selector Pulldown Menu > Layers Pulldown Menu > Interaction Mode Pulldown Menu > Operator tools properties
On the top header next to the tabs if possible keep only the ones that may not fit into the same hierarchy like Render Engine selection and Screen Layout which are transversal to all.

There actually is some hierarchy in the current alignment of items:

• The first bar contains items that are global/per-window/per-scene. The Blender icon-button and the menus are global, the workspace tabs and the scene switch are per window. The render engine menu is supposed to be moved to the render-layer settings or at least into the properties editor to my knowledge, so its current position is just temporary.
• The lower bar contains per-workspace settings (object mode, screen-layout, render-layer) and the global last operator settings.

So the hierarchy is that the upper bar contains items that are not per workspace, the lower bar per workspace ones. The last operator settings are an exception to this rule because of space usage, but think this exception is fine.
I guess this hierarchy becomes more clear and makes more sense when using it. I'd expect this to be the best or most reasonable structure, but maybe others disagree :)

Thanks for the quick review @Brecht Van Lommel (brecht)!

In D2759#64949, @Aleksandr Zinovev (raa) wrote:

Is there any urgency in fixing the issue?

Nope, the issue can be fixed by a python script. Let's commit the patch after 2.79 release.

Alright. You can just push to blender2.8 branch then, it's unlikely that there will be another feature release in-between :)

Looking fine, just one super picky suggestion.

Noticed there are some unwanted changes caused by merges (related to linking & transform orientations mainly). Please ignore, will remove them soon.

Eeek, just found about this. I submitted a similar patch ages ago (D763), although I reorganized scripting related menu entries into a submenu.
I'd be fine with applying this patch and adding the scripting submenu separately. However we should really do both to keep the menu organized.

Committed rBf1d6bad4b6f9f6. Thanks a lot for investigating and fixing! :)

Committed rB920bff522483cf. Thanks @Aleksandr Zinovev (raa) for raising awareness and attempting to fix! (Even if we ended up going with a different solution ;) )

Hmm, am not so sure about this. Using UI_BLOCK_BOUNDS_POPUP_MOUSE doesn't seem right since the issue may also occur on menus not bound to the mouse. Adding an extra flag... don't really like this either.

LGTM

Spent some time investigating this and noticed the difference to master is that the file-open handler is not stored in wmWindow.modalhandlers but in wmWindow.handlers, which have a much lower priority. So probably some other handler returned WM_HANDLER_BREAK, blocking the handling of wmWindow.handlers (just guessing on this, didn't investigate deeper).

Also reopening as design task. Like I said, this change seems to be crucial to some people.

Even though the workflow people used with the old behavior may abuse the original idea of the feature, I'd say we should keep supporting it. Maybe not many people use "Lock to Cursor" at all, but apparently for those who do, this change is crucial. BTW, I don't remember hearing anybody complain about the old behavior.