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

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
First-time contributor

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)*
quackarooni added 1 commit 2024-01-15 14:07:17 +01:00
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
Author
First-time contributor

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.)*
quackarooni requested review from Lukas Tönne 2024-01-15 14:21:30 +01:00
Member

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?
Author
First-time contributor

@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.
Member

@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.
Member

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.
Author
First-time contributor

@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.
First-time contributor

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.
Contributor

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.
First-time contributor

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.)
First-time contributor

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.
This pull request has changes conflicting with the target branch.
  • scripts/startup/bl_operators/node.py

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.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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
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.