WIP: Experiment: Invert Alt Behavior for Multi-Editing Tests #111093

Harley Acheson · 2023-08-13T18:56:11+02:00

Harley Acheson commented

2023-08-13 18:56:11 +02:00

Experimental patch that makes multi-object editing default behavior.

This isn't useful on its own, but I wanted this on Gitea so it can act as a starting point for me and others to experiment with, improve, or complete.

Once applied if you have multiple objects selected then changing properties will affect all of them. You can hold down ALT to affect only the active object. Basically the opposite of how it is now. Although this generally "works", what is very incomplete is good user feedback. Not all properties work with multi-object editing and there is no way to tell which is which.

Another problem is that values for the active object are shown, rather than something informing that the value is indeterminate. We do now have an "indeterminate" state though. Adding UI_BUT_INDETERMINATE to any uiBut's drawflag will make it show it show a long dash. Examples here: #108210. But this patch does not do so. Not sure when and where to do this or determine which ones to affect.

With this patch applied this does exhibit the bad behavior shown in https://archive.blender.org/developer/maniphest/0053/0053950/index.html but note you would have to set up the situation manually as the blend file included in the report is too old.

Experimental patch that makes multi-object editing default behavior. --- This isn't useful on its own, but I wanted this on Gitea so it can act as a starting point for me and others to experiment with, improve, or complete. Once applied if you have multiple objects selected then changing properties will affect all of them. You can hold down ALT to affect only the active object. Basically the opposite of how it is now. Although this generally "works", what is very incomplete is good user feedback. Not all properties work with multi-object editing and there is no way to tell which is which. Another problem is that values for the active object are shown, rather than something informing that the value is indeterminate. We do now have an "indeterminate" state though. Adding UI_BUT_INDETERMINATE to any uiBut's drawflag will make it show it show a long dash. Examples here: #108210. But this patch does not do so. Not sure when and where to do this or determine which ones to affect. With this patch applied this does exhibit the bad behavior shown in https://archive.blender.org/developer/maniphest/0053/0053950/index.html but note you would have to set up the situation manually as the blend file included in the report is too old.

👍 7 ❤️ 10 🚀 6

Harley Acheson added 1 commit 2023-08-13 18:56:24 +02:00

WIP: Multi Object Properties Editing d4f8624b53

Experimental patch that makes multi-object editing default behavior.

Harley Acheson referenced this pull request

2023-08-13 19:05:03 +02:00

Multi-Object Properties Editing #54862

Harley Acheson added this to the User Interface project 2023-08-13 23:05:38 +02:00

William Reynish commented

2023-08-15 15:54:43 +02:00

First-time contributor

Wonderful. The next challenge then, is also to make it so the properties users see aren't just the ones that belong to the active object.

The most straightforward solution here seems to be to only show those properties that the selected objects have in common, and just disregard the active object.

Wonderful. The next challenge then, is also to make it so the properties users see aren't just the ones that belong to the active object. The most straightforward solution here seems to be to only show those properties that the selected objects have in common, and just disregard the active object.

Duarte Farrajota Ramos commented

2023-08-16 00:17:50 +02:00

First-time contributor

Would it be a valid option to show multiple object data tabs side by side when more than one object type is selected?

Each one would affect properties for all selected objects of that type.
For properties that will affect more than one object maybe show the number of affected objects in brackets like (7)

Would it be a valid option to show multiple object data tabs side by side when more than one object type is selected? ![bse.png](/attachments/00b9882b-1d3a-4425-8ce5-17003030e32b) Each one would affect properties for all selected objects of that type. For properties that will affect more than one object maybe show the number of affected objects in brackets like _(7)_

bse.png

48 KiB

❤️ 2

Harley Acheson added 1 commit 2023-09-19 00:39:29 +02:00

Merge branch 'main' of projects.blender.org:blender/blender into MultiObjectEditing edad4ba552

Harley Acheson referenced this pull request

2024-03-01 00:06:42 +01:00

Roadmap #118940

Julian Eisel commented

2024-03-28 16:35:10 +01:00

The title of this PR is misleading since it sounds like there's active work on multi object properties editing ("object" is also a bit misleading btw, since this affects far more than objects btw), and that this is the PR for it. In reality this just inverts the alt key behavior making multi-editing the default; a lot of work would be needed to make this ready, and this isn't being worked on actively. #54862 outlines a number of design features that would have to be implemented, and as Brecht recently pointed out, a lot more design work is needed.

Dalai suggested this should be a PR in your personal repository only even, if the idea is to have it as a reference or starting point. Think this makes sense. I'd suggest a title like "Experiment: Invert alt key behavior to enable multi-editing by default", or something similar that actually describes what the PR does.

With the UI module being more active/organized again, the idea is to pick up tasks like these as multi week/month projects for the entire module to focus on, and hopefully we can start doing that in a few months. But there may be other priorities still, like better handling of unused data.

The title of this PR is misleading since it sounds like there's active work on multi object properties editing ("object" is also a bit misleading btw, since this affects far more than objects btw), and that this is the PR for it. In reality this just inverts the alt key behavior making multi-editing the default; a lot of work would be needed to make this ready, and this isn't being worked on actively. #54862 outlines a number of design features that would have to be implemented, and as Brecht recently pointed out, a lot more design work is needed. Dalai suggested this should be a PR in your personal repository only even, if the idea is to have it as a reference or starting point. Think this makes sense. I'd suggest a title like "Experiment: Invert alt key behavior to enable multi-editing by default", or something similar that actually describes what the PR does. --- With the UI module being more active/organized again, the idea is to pick up tasks like these as multi week/month projects for the entire module to focus on, and hopefully we can start doing that in a few months. But there may be other priorities still, like better handling of unused data.

👍 2

Harley Acheson changed title from ~~WIP: Multi Object Properties Editing~~ to Experiment: Invert Alt Behavior for Multi-Editing Tests

2024-03-28 16:57:03 +01:00

Harley Acheson changed title from ~~Experiment: Invert Alt Behavior for Multi-Editing Tests~~ to WIP: Experiment: Invert Alt Behavior for Multi-Editing Tests

2024-03-28 16:58:27 +01:00

Ludvik Koutny referenced this pull request

2024-04-04 09:31:14 +02:00

Smooth by Angle Usability Improvements #120230

This pull request has changes conflicting with the target branch.

source/blender/editors/interface/interface_handlers.cc

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u MultiObjectEditing:Harley-MultiObjectEditing

git checkout Harley-MultiObjectEditing

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: Experiment: Invert Alt Behavior for Multi-Editing Tests #111093

Checkout