- User Since
- Dec 12 2013, 11:11 PM (197 w, 22 h)
Wed, Sep 20
Sat, Sep 16
Fri, Sep 15
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.
Wed, Sep 13
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.
Wed, Sep 6
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.
Mon, Sep 4
Mon, Aug 28
Aug 18 2017
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).
Aug 12 2017
Aug 9 2017
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).
Aug 7 2017
Aug 2 2017
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.
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)!
Aug 1 2017
Jul 31 2017
Jul 30 2017
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.
Jul 29 2017
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.
Jul 28 2017
Jul 27 2017
Committed rBf1d6bad4b6f9f6. Thanks a lot for investigating and fixing! :)
Jul 26 2017
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.
Jul 19 2017
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).
Jul 18 2017
Jul 17 2017
Jul 13 2017
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.