two TINY usability fixes in the node editor #35910
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#35910
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
%%%This patch includes fixes for some tiny new-user usability issues in the node editor...
Why change this?
This is because currently the node-group-edit mode is very easy for new users to get "stuck" in, because that up-arrow is tiny and non-obvious as a way to leave the mode.
Why is this change a good one?
a. places modal-group-toggles in the front, so they are more obvious, harder to be "offscreen" due to space limitations -- and the same place as the similar object/edit mode toggle in 3dview
b. the text "Up to Parent" is very much like the fullscreen exit "Back to Previous", and makes this button easier to find when it's needed
c. this should cause minimal impact to expert users.. it's a minor increase in toolbar length... though this similar function gets the same visual space as object/edit mode toggle, so it seems reasonable.
Why?
The "Edit Group" toggle in this menu only toggles between the last two edit groups. When the group depth exceeds 1, the "Up to Parent" function is needed to get out of group-edit. Therefore, it seems logical to place this next to the "Edit Group" in the menu. This also helps with the same user-confuction from #1, because there is an additional place for them to find the "Up to Parent" action.
http://blender.stackexchange.com/questions/730/what-does-use-the-pinned-node-tree-do
%%%
Changed status to: 'Open'
%%%I think the existing button order could be improved, but not sure this new one is right. Buttons typically go from general to specific and this places navigation/pinning of a specific node tree before the more general scene/texture/material choice?
Perhaps pin button should aligned on the right of the datablock choosing widget to make it clear what it is pinning. Also confusing here is that the pin button shows for scene compositing nodes but it does not appear to have any function there.
Up to Parent in the menu is fine, though it could perhaps be hidden instead of disabled, and maybe just say Parent in the label to save some space?
Lukas, what do you think?%%%
%%%> I think the existing button order could be improved, but not sure this new one is right. Buttons typically go from general to specific and this places navigation/pinning of a specific node tree before the more general scene/texture/material choice?
I agree 100%. It should be "node-tree-type" selection, followed by the up/pin "navigation"
I tested this and it does have a function for scene compositing nodes! If you pin, you can switch the scene and the editor does not change. aka, it allows you to pin node-configs for different compositing scenes into view.
I don't know exactly what you mean by "datablock choosing widget", are you talking about the tree-type-selector (compositing/texture/shader)? I agree this seems like a reasonable place to put it, since the pin applies only to the currently selected tree-type.
A related issue is that when you pin something, there is no UI to show you what you have pinned. (aka, if you pin Scene 1 into one compositing node editor, and make another one pinned to scene 2, there is no way I can see for you to tell which is which)
I considered hiding it when disabled but was concerned the "shifting" of the toolbar would be undesirable. If this is acceptable, I think that is a great choice, because it will also make it more obvious.
%%%
%%%I made a new version of the patch based on suggestions:
I left the titles both "Up to Parent", since I think this is more clear than "Parent" which sounds like it could be a change action like "Make Parent" instead of a navigation.
%%%
%%%also... I did not see an easy way to "attach" the pin operator button to the tree-type-selection, since the tree-type selection is a single operator. (see new screenshots)%%%
%%%....as a semi-related note on "Pinning"...
The node-space pin acts on all three tree-types, even though the user probably was only thinking about a single-tree-type when they clicked the pin.
I don't use the pinning functionality, so I'm not sure what user-expectation is here. It might make sense for the "pin" to prevent tree-type changes to avoid confusion about what is being pinned ... or users might rely on being able to pin all three contexts? Either way, perhaps when pinned there could be a new view-property-sidebar "Pinned", which would detail the three contexts which are pinned. Or perhaps it could be labeled "Contexts", be always present, and include the pin button itself. I don't have a strong feeling about any of these because I don't use the pinning functionality. %%%
%%%ping.. any word on this? any feedback?%%%
%%%Regarding the pinning button, see the image editor. It also has a pin button next to images, but just on the right of the datablock widget (browse name F + X). Anyway, not really a big deal because it's used a bit different here. This could be committed for 2.69, right now svn is open for bug fixes only.
The pinning in general works confusing here, you can pin material nodes but it actually keeps showing the material from the context in the header, which then is different from the one displayed.%%%
Up to Parent
The "Up to parent" button is there mostly to complement the node group operator for opening/closing groups (tab key). Before pynodes changes this was very simple because node groups had only one level and could be treated like edit mode on objects. But since you can now have nested node groups there can be ambiguous cases:
I agree to moving this further left, because as Brecht said, generic buttons should come first. Not sure about adding the label to it, i would use "Parent" as a compromise to not take up too much space.
Pinning
This is indeed confusing, it's a problem with the way node trees are stored inside Material/Texture/Scene data blocks and how we display these container blocks in the node editor header, pretending they are the actual node tree. Pinning in the node editor pins nodes, which should be uncontroversial by itself, but the mixing with other data blocks adds confusion.
Pinning becomes most useful when using node groups, it enables you to work on a group (which is an independent NodeTree data block) while changing context. If all node trees were consistent data blocks in the library this problem wouldn't exist ...
I'll see if i can clean up the header drawing such that the ID link button is in sync with what the node editor actually displays (see also #36589 and
562313b
)Added subscriber: @ideasman42
Lukas, any update on this?
Note that UI changes could also be applied to the sequencer
Changed status from 'Open' to: 'Archived'
I'm going to archive this now. I'll leave further decisions to the UI team.