blender
/
blender
131
398
Fork 577
Code Issues 6.2k Pull Requests 747 Projects 19 Wiki Activity

Nodes: Added "Move Item" operator for re-ordering nodegroup sockets and panels #117130

Open
quackarooni wants to merge 1 commits from quackarooni/blender:nodegroup_move_item_operator into main
pull from: quackarooni/blender:nodegroup_move_item_operator
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 10 Commits 1 Files Changed 2 +98 -1
quackarooni commented 2024-01-15 14:07:10 +01:00
First-time contributor
Copy Link

Problem

Following the addition of nodegroup panels in Blender 4.0, the method of for re-ordering nodegroup items (i.e. sockets and panels), got changed to a 'click-and-drag' system. While this approach is good for allowing you to directly position items where you'd want them to be, it also presents a couple of usability issues.

Namely, requiring users to hold the mouse button to reposition items:

  1. Makes it difficult for users that rely on hardware devices such as trackpads instead of mice.
  2. Makes re-ordering items quite error-prone as the mouse button could be accidentally released before the cursor is in the desired position.

Solution

In versions prior to 4.0, operators for re-ordering sockets were available in the form of buttons on the side of the inputs/outputs panel.
Clicking on these moves the active item one step up/down, depending on which button was pressed.

This commit aims to implement the same functionality but for the current nodegroup system. Having this as an available option for re-ordering nodegroup items should ease some of the usability issues mentioned above, as this does not require the user to maintain hold of the mouse button. (Note: The .blend file used in this test available in the files below)

Technical Details

A brief overview of how the operator works is as follows:

  • Nodegroup items of the same type are re-ordered amongst each other.
    (i.e. Input sockets with other input sockets, output sockets with other output sockets, and panels with other panels)
  • If an input/output socket is the first of its type in its current panel, moving it up puts it in the panel before its current one. (if one exists)
  • If an input/output socket is the last of its type in its current panel, moving it down puts it in the panel after its current one. (if one exists)
## Problem Following the addition of nodegroup panels in Blender 4.0, the method of for re-ordering nodegroup items *(i.e. sockets and panels)*, got changed to a 'click-and-drag' system. While this approach is good for allowing you to directly position items where you'd want them to be, it also presents a couple of usability issues. Namely, requiring users to hold the mouse button to reposition items: 1. Makes it difficult for users that rely on hardware devices such as trackpads instead of mice. 2. Makes re-ordering items quite error-prone as the mouse button could be accidentally released before the cursor is in the desired position. ## Solution In versions prior to 4.0, operators for re-ordering sockets were available in the form of buttons on the side of the inputs/outputs panel. Clicking on these moves the active item one step up/down, depending on which button was pressed. <video src="/attachments/195ff18e-9638-4a0e-9ce4-e119a28fa0b4" title="Move Items Operator - Demo Video.mp4" controls></video> This commit aims to implement the same functionality but for the current nodegroup system. Having this as an available option for re-ordering nodegroup items should ease some of the usability issues mentioned above, as this does not require the user to maintain hold of the mouse button. *(Note: The .blend file used in this test available in the files below)* ## Technical Details A brief overview of how the operator works is as follows: - Nodegroup items of the same type are re-ordered amongst each other. *(i.e. Input sockets with other input sockets, output sockets with other output sockets, and panels with other panels)* - If an input/output socket is **the first of its type** in its current panel, moving it up puts it in the panel **before** its current one. *(if one exists)* - If an input/output socket is **the last of its type** in its current panel, moving it down puts it in the panel **after** its current one. *(if one exists)*
Move Items Operator - Test File - [4.1].blend
118 KiB
Move Items Operator - Demo Video.mp4
21 MiB
👀 3 ❤️ 3 🎉 1
quackarooni added 1 commit 2024-01-15 14:07:17 +01:00
f8ad73a483 Added "Move Item" operator for nodegroup items 
Implemented operators for re-ordering node interface items.
Functionality is similar to `node.tree_socket_move` in versions prior to 4.0.

Though this version is made to also support re-ordering panels,
and re-ordering sockets across them.
Iliya Katushenock added this to the User Interface project 2024-01-15 14:15:45 +01:00
Iliya Katushenock added the
Interest
Nodes & Physics
 label 2024-01-15 14:16:39 +01:00
quackarooni commented 2024-01-15 14:20:49 +01:00
Author
First-time contributor
Copy Link

Other Considerations

Move Items Operator - UI Problem.png

Adding the buttons for these does make the UI a tiny bit wonky if there's only a small amount of items in the nodegroup.
I thought this might be worth bringing up as the section responsible for drawing the nodegroup items is not editable in Python, so I can't do much to control the height for that.

It's not the biggest problem in the world, in my opinion. But if someone else deems it necessary to make these heights match, they'll prolly have to touch parts C/C++ code for that. (I wish I could do that myself, but that's a bit outside of my current skill level.)

## Other Considerations ![Move Items Operator - UI Problem.png](/attachments/6413ca64-2d83-4a0f-8ef1-ca076b8d68ea) Adding the buttons for these does make the UI a tiny bit wonky if there's only a small amount of items in the nodegroup. I thought this might be worth bringing up as the section responsible for drawing the nodegroup items is not editable in Python, so I can't do much to control the height for that. It's not the biggest problem in the world, in my opinion. But if someone else deems it necessary to make these heights match, they'll prolly have to touch parts C/C++ code for that. *(I wish I could do that myself, but that's a bit outside of my current skill level.)*
Move Items Operator - UI Problem.png
9.1 KiB
quackarooni requested review from Lukas Tönne 2024-01-15 14:21:30 +01:00
Lukas Tönne commented 2024-01-15 14:25:50 +01:00
Member
Copy Link

I initially added these operators, but during UI discussion they were considered redundant.
@dfelinto anything you want to add?

I initially added these operators, but during UI discussion they were considered redundant. @dfelinto anything you want to add?
quackarooni commented 2024-01-15 14:27:31 +01:00
Author
First-time contributor
Copy Link

@LukasTonne I tagged you for review since it seems like you did a lot of the work for the new nodegroup system in 4.0.

If there's any revisions/edits I need to make for this to get merged, I'll try my best to implement them.
Though I'll have to note I'm mainly a Python dev, and don't have much experience with C/C++ (So I'm largely restricted by that)

If there's someone else I should tag for review here, feel free let me know as well.

@LukasTonne I tagged you for review since it seems like you did a lot of the work for the new nodegroup system in 4.0. If there's any revisions/edits I need to make for this to get merged, I'll try my best to implement them. Though I'll have to note I'm mainly a Python dev, and don't have much experience with C/C++ *(So I'm largely restricted by that)* If there's someone else I should tag for review here, feel free let me know as well.
Lukas Tönne commented 2024-01-15 14:42:26 +01:00
Member
Copy Link

@quackarooni I haven't looked at the code yet. I just wanted to point out that removing these buttons was a deliberate decision. So before considering this i'd like to have feedback from the UI team.

@quackarooni I haven't looked at the code yet. I just wanted to point out that removing these buttons was a deliberate decision. So before considering this i'd like to have feedback from the UI team.
👍 1
Hans Goudey commented 2024-01-15 15:04:34 +01:00
Member
Copy Link

There are some simple improvements to drag and drop reordering that would make the situation much better. For example, a line should be drawn in between two items when the drag and drop will put the item there. Or a panel should be highlighted somehow to show when an item will be added to it.

I would definitely prioritize improving drag and drop before adding these buttons back. They add clutter, and other software doesn't seem to need them.

There are some simple improvements to drag and drop reordering that would make the situation much better. For example, a line should be drawn in between two items when the drag and drop will put the item there. Or a panel should be highlighted somehow to show when an item will be added to it. I would definitely prioritize improving drag and drop before adding these buttons back. They add clutter, and other software doesn't seem to need them.
👍 2
quackarooni commented 2024-01-15 15:13:53 +01:00
Author
First-time contributor
Copy Link

@quackarooni I haven't looked at the code yet. I just wanted to point out that removing these buttons was a deliberate decision. So before considering this i'd like to have feedback from the UI team.

No worries, I do hope having the buttons there is at least worthy of a bit of reconsideration.

I've outlined in PR message above some of the usability issues I have with the current system, I frequently face those when I use Blender on a laptop as opposed to a PC. While none of these issues are game-breaking overall, they do make the experience a bit clunkier or more annoying.

Granted that's just one perspective among many, so I'm fine with conceding if it's ultimately deemed that these features are not worth re-implementing.

> @quackarooni I haven't looked at the code yet. I just wanted to point out that removing these buttons was a deliberate decision. So before considering this i'd like to have feedback from the UI team. No worries, I do hope having the buttons there is at least worthy of a bit of reconsideration. I've outlined in PR message above some of the usability issues I have with the current system, I frequently face those when I use Blender on a laptop as opposed to a PC. While none of these issues are game-breaking overall, they do make the experience a bit clunkier or more annoying. Granted that's just one perspective among many, so I'm fine with conceding if it's ultimately deemed that these features are not worth re-implementing.
Gurra commented 2024-01-15 19:44:49 +01:00
First-time contributor
Copy Link

While I do welcome the click and drag functionality we got in 4.0 for moving items long distances in the list, I (and others as well that I've noticed) do still miss the buttons since they are a faster and more "stable" way of moving items short distances, so I really think we could have both. They might add a tiny bit of clutter, but it's not bad at all imo.

While I do welcome the click and drag functionality we got in 4.0 for moving items long distances in the list, I (and others as well that I've noticed) do still miss the buttons since they are a faster and more "stable" way of moving items short distances, so I really think we could have both. They might add a tiny bit of clutter, but it's not bad at all imo.
Mahid Sheikh commented 2024-01-15 21:10:50 +01:00
First-time contributor
Copy Link

As someone who works primarially on a laptop, the arrows are incredibly useful when on the go. Sure, the new touch and drag isn't thar big of a deal breaker, but for complex node groups, I feel that the arrows help with overall user experience.

As someone who works primarially on a laptop, the arrows are incredibly useful when on the go. Sure, the new touch and drag isn't thar big of a deal breaker, but for complex node groups, I feel that the arrows help with overall user experience.
Chris commented 2024-01-16 07:59:27 +01:00
First-time contributor
Copy Link

This is an absolute must as far as I'm concerned. As others have mentioned the arrows are more stable, predictable and easier to use for laptop users, those with accessibility issues and generally people who prefer the control the arrows give you. However on top of that, given that the in/out panel does not have the ability to be shrunk and scrolled, and there is no auto scrolling option for dragging items, as soon as the list extends past what a monitor is capable of showing at full screen (Easier than ever now that the inputs and outputs are part of the same panel, and node panel groups can only exist at the end of the list for both inputs and outputs) reordering can easily become a cumbersome, frustrating, multi-step process of moving it as far as possible, manually scrolling the side panel, and dragging it again. Frankly this is an absurd behaviour that is needlessly frustrating and slows down workflow; and while the arrows would still require manually scrolling to the item you want to move and then back up the arrows, at least the entire move can be made from there without further extraneous navigation. (This is made even more painful when the fact that all input/output options are located beneath the list is considered, causing an unnecessary and frustrating amount of time and effort to be spent constantly scrolling up and down to select items and change their options.)

As an additional aside, the in/out panel in general is clunky and visually confusing to parse when there are 2 text-only prompts to signify placing an item in the same spot that will rapidly switch when hovering over the what a user expects to be a constant location. Doubley so when the Outliner already has a perfectly viable solution in showing a line where the item will be placed that users are already accustomed to.

So for me, to make the in/out panel, at a minimum, not highly frustrating for anything beyond basic work, requires:
-Re-addition of the arrows
-Visually clearer representation of where an item will be placed when click-dragging
-And either the ability for the list to auto scroll when dragging, or the ability to shrink the panel and scroll within it, preferably both.

(And since we're here anyways: the lack of multi-selection means the process of creating and managing panels or large amounts of inputs/outputs in general is a needlessly long and frustrating process of moving individual items, made exponentially worse by everything mentioned above.)

This is an absolute must as far as I'm concerned. As others have mentioned the arrows are more stable, predictable and easier to use for laptop users, those with accessibility issues and generally people who prefer the control the arrows give you. However on top of that, given that the in/out panel does not have the ability to be shrunk and scrolled, and there is no auto scrolling option for dragging items, as soon as the list extends past what a monitor is capable of showing at full screen (Easier than ever now that the inputs and outputs are part of the same panel, and node panel groups can only exist at the end of the list for both inputs and outputs) reordering can easily become a cumbersome, frustrating, multi-step process of moving it as far as possible, manually scrolling the side panel, and dragging it again. Frankly this is an absurd behaviour that is needlessly frustrating and slows down workflow; and while the arrows would still require manually scrolling to the item you want to move and then back up the arrows, at least the entire move can be made from there without further extraneous navigation. (This is made even more painful when the fact that all input/output options are located beneath the list is considered, causing an unnecessary and frustrating amount of time and effort to be spent constantly scrolling up and down to select items and change their options.) As an additional aside, the in/out panel in general is clunky and visually confusing to parse when there are 2 text-only prompts to signify placing an item in the same spot that will rapidly switch when hovering over the what a user expects to be a constant location. Doubley so when the Outliner already has a perfectly viable solution in showing a line where the item will be placed that users are already accustomed to. So for me, to make the in/out panel, at a minimum, not highly frustrating for anything beyond basic work, requires: -Re-addition of the arrows -Visually clearer representation of where an item will be placed when click-dragging -And either the ability for the list to auto scroll when dragging, or the ability to shrink the panel and scroll within it, preferably both. (And since we're here anyways: the lack of multi-selection means the process of creating and managing panels or large amounts of inputs/outputs in general is a needlessly long and frustrating process of moving individual items, made exponentially worse by everything mentioned above.)
Erindale commented 2024-01-26 14:55:37 +01:00
First-time contributor
Copy Link

I definitely hear the accessibility concern for click-drag but I think that could be covered with an input preferences option to change click hold to click-on/click-off.
Up down buttons are sometimes useful I agree but I think the main issue is just that the current drag UX for node sockets feels very unfinished. Blender already has a really nice UX for reordering panels so we should just use that for consistency.
Loads of other software gets by totally fine with drag for reordering layers in painting software and other things so I don't think the interaction is fundamentally at fault.

edit: Worth noting as well that reordering panels out of the view space will also handle the auto-scrolling, and we got the node position autoscrolling the node canvas so that is an interaction that users are already trained to expect.

I definitely hear the accessibility concern for click-drag but I think that could be covered with an input preferences option to change click hold to click-on/click-off. Up down buttons are sometimes useful I agree but I think the main issue is just that the current drag UX for node sockets feels very unfinished. Blender already has a really nice UX for reordering panels so we should just use that for consistency. Loads of other software gets by totally fine with drag for reordering layers in painting software and other things so I don't think the interaction is fundamentally at fault. edit: Worth noting as well that reordering panels out of the view space will also handle the auto-scrolling, and we got the node position autoscrolling the node canvas so that is an interaction that users are already trained to expect.
dragdrop.gif
181 KiB
dragdrop.gif
❤️ 3
This pull request has changes conflicting with the target branch.
  • scripts/startup/bl_operators/node.py
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u nodegroup_move_item_operator:quackarooni-nodegroup_move_item_operator
git checkout quackarooni-nodegroup_move_item_operator
Sign in to join this conversation.
Reviewers
No reviewers
Lukas Tönne
Labels
Clear labels   
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
This issue affects/is about backward or forward 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
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
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
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
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 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
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
User Interface
Assignees
Clear assignees
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117130
No description provided.
Delete Branch "quackarooni/blender:nodegroup_move_item_operator"

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?