Stronger binding of Active and Selected #82359
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
30 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#82359
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?
Context
For many things that can be Selected, there is also a state called Active. There can be 0..∞ Selected things, and 0..1 Active things. This applies to objects, bones, fcurves, fcurve keys, mesh elements, and more. These will just be referred to as thing in this task to avoid having to repeat that entire list.
The Selected and Active states are independent, so there are four states a thing can be in:
Problem
There are two states possible that can cause issues:
Related Reports
These reports are examples of confusing situations where the disconnect between Active and Selected. The list is not exhaustive, and may be expanded later.
Proposal
This design task proposes linking Active and Selected such that:
Hurdles to Overcome
Rule 1. above requires that one of the selected things is marked active. There is not always a unique, obvious choice here, for example when box-selecting multiple things at the same time. In this case the choice should at least be consistent so that users know what to expect after a while. The thing closest to the mouse cursor (when using the mouse to select) could be a reasonable choice.
Rule 2. above can be dealt with in various ways:
983ad4210b). This has the downside that now nothing is active, breaking rule 1 and forcing the selection-changing code to pick another thing to become Active.Goal of this Design Task
The goal of this design task is to answer the following questions:
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @dr.sybren, @LucianoMunoz
Added subscriber: @lichtwerk
Added subscriber: @ChrisLend
Not a fan of this. I am not familiar with the selection code, but I am assuming selection is stored in a list. If the active object is deselected, the last object in the selection list should become active.
When box selecting (or any multi select) I think we could set the last object returned by the selection process to be active. This is somewhat random, but I think it doesn't matter as long as it's consistent.
If I need a specific object to be active, I need to select it afterwards anyway.
In general it's a good idea to discuss this. I agree it doesn't make sense to have something active but not selected
Yes I agree, deselecting the active thing should make an other selected thing active, ideally the last one in the order of selection... Is selection order a thing in blender?
Added subscriber: @JulienKaspar
I recall a similar discussion during the 2.80 alpha where the behavior was changed a couple times. Back then it was about hiding objects and if hidden objects should be allowed to be selected/active.
The resolution was that hidden objects cannot be selected but can be active since there are benefits to keeping the data of an active object in the properties editor visible even while it is not selected/visible at that moment.
There is also the solution of pinning the data block in the properties editor but that workflow is slower. Some tabs can also not properly be pinned since they contain multiple data blocks (object data tab includes the key data block)
IMO if the pinning would get some improvements I could see it working that deselected objects cannot be active.
Another thing I can think of is that it would be important that when hiding and unhiding things it would remember which one used to be active and then make it active again.
It should never feel random which thing is going to be the active one.
Add this weird/confusing case: Active but not selected
active but not selected.mp4
Me neither, but it's an approach and I just wanted to have it mentioned.
Selection state is stored on the things themselves, and not as a separate list of selected-thing-references. This also means that there is no sensible order to the selection state; there is no "last object in the list".
Well, consistent and random are quite the opposite. I don't think that "the last bone that was loaded when that library override system processed it" or "the object that happened to be put last in memory while parallel-loading five different blend files" are reasonable things to pick.
True, but that shouldn't get in the way of us making it reliable & predictable. For example, a closest-to-mouse approach could influence in which direction you box-select.
It is not. I also don't think we should depend on this. For example, say you have bones A-F selected, and then you box-select bones E-H. What's the selection order? If bone A was the active one, how does selection order tell you which should be the next active bone?
Thanks for the historical view, this makes sense and should be considered here as well. I do agree that things can get very nasty when you modify something you cannot see, which is what the "hidden objects may not be selected" thing was about.
This is what happens with the active keyframe right now. When it's not selected, the function to get the active keyframe will feighn ignorance and say "nooo, nothing is active, reeeealy", and when the "active" keyframe is selected again, that same function will just return it as the active one.
Yes, very much so.
Added subscriber: @ideasman42
As this is such an important topic, I'll hold off on a full discussion that goes into possible solutions until bug-fix week is over.
Notes relating to changing the active object behavior:
For objects years back I tried linking active to selection, this causes the UI to flicker since toggling selection for example, makes the property editor flicker in a way that wasn't so nice.
The active object also defines the mode the user is in, so if (using the outliner or python API) and object becomes de-selected, this would exit the mode.
Some discussion on this topic: D4217: Select new active element using box/circle/lasso select [WIP]
Picking an active item for the user could cause all sorts of problems, as an item could be technically visible, yet hidden for all intents and purposes.
While the current situation can cause issues, any solution to this is likely to cause issues too (picking the active item for the user has many side-effects).
Currently the active+selected situation is a bit odd/quirky, yet, its a simple mental modal: The active is effectively "last picked", as a user this didn't bother me.
You know what you last picked, you can toggle the selection, add to it with box select, lasso etc, and you never need to think - did Blender change what I "last picked".
Not to say it's the best design, just that it's predictable.
My main concern is the solution is likely to have a more complicated mental model, users will try to understand/second-guess how Blender is tracking the active - or be dissatisfied with the behavior when it's not working how they would expect it to.
A design that handles this well might need to make much bigger changes to how Blender uses the active object.
Added subscriber: @PabloFournier
Animators at the studio are having problems related to this issue, I'm trying to create a cycle modifier on multiple bones at the same time, the problem is if i try to select all the channels by pressing A here
I dont see the modifier menu
I need to do stuff like deselect and select back one channel with shift to show the menu
Added subscriber: @SimonThommes
Added subscriber: @brecht
I think the long term solution here is to remove the concept of "active" for the most part, and have multi-object properties editing (#54862) everywhere instead.
The current situation has issues, but I'm not sure the proposed changes here are really better, since it's unpredictable in other ways.
how would you handle creating constrains? how would you handle parenting? how would you handle copying modifiers or other options from one object to other ones?
I think if we come up with a solution which is predictable enough I think we can nail it, then making editing every selected object's property by default instead of using alt still shouldn't be a big deal (I'm all up for that, it makes much more sense to affect all the selected objects than just the active one and alternatively we could shift the "alt" behaviour so you can still affect only the active one)
What if when doing box/circle/lasso select we assign the active to the closest to the cursor at the end of the selection?
No screenshots of other software please.
https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html
For defining relations between objects and a few other things, the concept of active is fine. It does not have to removed entirely. But it would be irrelevant most of the time with multi-object properties editing.
sorry, my bad!.
Yes it can be irrelevant in other things but having it allows for great workflows like "rotate to the pivot of the active object" which we cant lose, its part of blender's beauty.
Added subscriber: @Mets
Note that Python code that relied on bpy.ops and setting an active object, may not have bothered to also set that active object as selected, so depending on the resolution here such addons may need to be updated.
I feel like due to the reasons Campbell outlined, it might be better to, instead of preventing the two problematic cases, we would improve support for them. For example, I think it wouldn't be the worst thing in the world if, after de-selecting a thing, it would still be indicated that it is the active one. It may certainly be confusing for new users, but that's already how Blender behaves anyways, it's just not indicated at all. This would also probably be the easiest solution, even though it re-defines the problem a bit. So themes would need three colors, "selected", "active", "selected+active".
Even after 10 years of using blender actively, deselecting and having something stay active still confuses me, sorry that's very personal.
with all due respect: I think that's adding more complexity to a matter that should be simple, selection should be simple and you shouldn't need to think much about it, otherwise it becomes a slow process which you don't want in the most performed action, and really adds no use case.
Shouldnt be too complex:
you shift click a new object into the selection it should be added and become active.
@LucianoMunoz
I strongly agree. The list you outlines should be the case for all "things" and not just objects.
Especially with the behavior of #54862 this should work really well and make selecting and setting things as active way more convenient (Although users will have to get used to point 3 of the list).
The biggest hurdle for me and probably others would be to get used to deselection causing the properties editor to switch to scene related tabs.
Maybe there's a clever solution to avoid that instead of having to use the pinning icon more often?
@Mets
For objects at least it's indicated. Just in a subtle way. If an object is active but deselected it will have a bright orange origin point in the viewport and a white highlight on its icon in the outliner.
If it would be more obvious (like with an outline) then users might actually think its still selected.
Yes I agree, this one seems to be the more "predictable" one for the user out of the options I've tested.
In <> it feels kind of random for me when you do such type of selection, but it hasn't bothered me at all.
To me really "unselected but active" when nothing is selected is not such a big deal, what breaks me is unselected but active when you have other things selected
So maybe the ruling should be "unselected but active" is okay, but unselected but active when there is an other selected object is Not okay.
When there is a selected object the active object should always lie within the selected ones never within the unselected.
So maybe
Added subscriber: @GeorgiaPacific
Added subscriber: @franMarz
For me point 2 of the proposal is a must, but I find having no active element sometimes really useful, at least this is the case for me while modeling. Let me explain:
I use almost all the time "Active Element" as "Snap Pivot Point" and "Snap With - Active" as Snapping method, and I perform box select for having no active element within the selection so the fall-back of snapping behaves as "Median Point" or "Center". That way I don't have to change the snapping configuration back and forth. I would indeed appreciate that deselecting the active element would have the side effect of getting a selection without active element, something expectable, to take advantage of that. I would have another problem with Merge, with now I have setted as merge At Last and, if it fails because there isn't an active element, perform merge At Center, so that I don't have to choose the method every time for such a common operation.
I'm sure this would impact my modeling workflow big time if changed as discussed so far. I don't know someone else's. I don't know if I'm the only one who sees that having an active element all the time would be annoying because it would add additional steps between selecting and operating without automatic workarounds possible like the ones I've just mentioned.
Added subscriber: @rjg
Perhaps it would be a good idea to also take a look at how hiding works in combination with what is active and selected. For instance this caused some confusion in #82359 in the context of hidden bones in pose mode.
Added subscriber: @Stan_Pancakes
Added subscriber: @jc4d
Added subscriber: @zeauro
But that makes sense when using active element as pivot.
If you want to scale things selected and get them closer to active object that you don't want to transform ; that corresponds to a frequent case where selected means transformed and active means point of reference of transformation.
There are cases where you want your reference to be transformed like the rest of selection.
And there will always be cases where you don't want that.
For that reason, it is very useful to support unselected active object with a selection.
Maybe, that is just the word Active that is not reflecting reality of use. It could be renamed Reference object. That would be a more valid denomination.
Surely, the lack of color to indicate an Unselected but Active element is problematic.
That does not happen in Object mode when Origins are indicating active status and absence of Outline is indicating Unselected status.
Real resolution is to find similar tricks in other modes : a way to to show unselected but active status.
But that is not the status the culprit of confusion. It is the lack of visual feedback to communicate it.
What is sure is that removing of the idea of a quick determination of an element of reference for transformations and snapping would impact negatively modeling workflow.
It would be a big mistake.
Added subscriber: @ckohl_art
Added subscriber: @IPv6
Proposal 2 is a must, this is definitely expected behaviour. What interesting with mentioned downsides of this: in case of extending of exisiting selection you will already inevitable have active element, so it will not changed. So there is no problem with choosing active element. The problem arise only when selection is created "en masse" - like A key in EDIT/OBJECT mode or L key in EDIT mode. And deselection of active item in current selection turns into same "selection initialization" problem basically
Choice based on closest to mouse position would not be great decision though, imho... mouse position is generally random, this will feel mostly broken.
Two possibilities/suggestions here:
Make active element closest to 3D cursor (vert in EDIT, object in OBJECT, etc) among selected. 3D cursor generally always floating around of "Point of interest" during modelling sessions, so this will give reasonable choice in many cases.
As addon developer, i must say there is a common flow of deselecting-reselecting verts in edit mode for different tasks. Would be great if this flow should be able to keep active verts.
So it would be great to keep shadow history of last position of most recent active element in space (like vert.co in global space. not verts itself, since they may change during operations) and after mass-selection just restore active element closest to this point
Also, it is expected that "active element enforcement" should happen after operator is finished or update_from_bmesh called. not on every "v.select = True", i mean
So suggesting a common procedure of selecting active element after any "selection initialization":
This just means that you're using some object as the 3D cursor. I'm wondering if it's worth the confusion of having active-but-not-selected as possible state. Why not just snap the cursor to whatever reference position you want to use?
This depends on which selection method is used. With circle select, mouse position is far from random. With {key A} the mouse could be anywhere, and indeed may not be the best choice. On the other hand, it does present something predictable, as artists generally know where their mouse is.
You could use the same "point of interest" argument for the mouse cursor as well. The advantage of using the 3D cursor is that it's already in 3D, so there is less issues with depth. On the other hand, pretty much every artist uses a mouse or other pointer device, but not all workflows use the 3D cursor.
I don't know if this is a good idea. In any case an add-on developer can already do this.
I agree.
It's very far from "just", it's quite a few UI interactions. Right now, all one needs to do is set pivot to "Active Element" and (at worst) make two additional shift+clicks and at best none at all. Let's consider the hypothetical that "active" no longer exists as a pivot. Now, one would need to destroy their existing selection to pick a pivot object, snap the cursor to it, then re-build their selection. Or rely on the cursor transform tool with snapping options which may or may not be configured for that kind of snapping (if they're not, yet more UI interactions).
Yes, user generaly knows where mouse is, but there is way too many cases when the mouse is 100% NOT at the "point of interest" regarding mesh/selection. When user clicks on operator button in the N panle - mouse will be in "random" position (regarding possible selection, created during operator execution). When user clicks on top menu item inside menu, to call some operator - mouse will be in "random" position, again. When user uses quick menu to make swipe gesture, use favorites or radial menu or pie menu, or right-click context menu, etc, etc - mouse will be definitely not around the place, where active item is expected to be.
The only case when mouse cursor can be placed on something meaningful - when user uses hotkeys. Pretty every other method to make something - will give "broken feel" (regarding active element defaults). Imho.
Added subscriber: @MadMinstrel
You have to either change your selection or change your tool to snap the cursor. This is just too slow if you have to perform the action repeatedly. Moreover, the cursor doesn't necessarily have the same orientation (that you can use for rotations) as a face or edge when snapped.
wait so you are saying than having to click and activate one of the objects in a selection is done less often than using an unselected object as pivot?
please count:
Every time you select and want to perform an action on the selected objects you need o make one of them active.
Thats about 1000 times a day.
Using an unselected object as pivot of the selected ones is a corner case.
@LucianoMunoz any operation that forces you to lose your current selection is a destructive operation. Selection is work, and may not be trivial to create. In fact, it is only trivial in trivial cases. Losing selection means losing work.
Obviously the frequency depends on what you're doing exactly. But more often than not you make a selection first and then decide where the pivot should be. So if you want to snap the cursor at that point, you have to destroy that selection, snap and recreate it - whereas setting the active element is just a shift-click.
If Blender let you freely pick your pivot point without affecting your selection, the whole thing about using the active element as the pivot would be a non-issue, but that is not currently the case. But that's a larger issue and rather out of scope here.
there are only 2 possible actions that you can be performing where the pivot is relevant, rotation and scale.
none of the countless other things you can do with a selection require a pivot where so I believe sacrificing "option" <> is a minor loss compared to the winning you'll get by not having to actively select the active object every time yo make a selection for something other than pivoting around an unselected object.
@LucianoMunoz: there are more than two. Snapping - both transform snapping, and Snap To operators - also can use active as pivot or base point, either directly or indirectly. Align to Transform Orientation as well.
Also, you're framing it backwards. You don't "have to" actively select active object every time. You can do that when you need it. It's a useful option. If that option is removed altogether, there has to be an alternative that does not require you to do more work. Destroying your selection only to define a custom pivot is more work.
Agreed, if you select the object where you want to place the 3D cursor you can just then undo twice and get back to your selection and the 3D cursor will stay in that place.
And your selection isn't lost.
That just abuses the fact that cursor placement is not currently undoable. And using undo as part of a forward action is a much worse UI problem than the current Active/Selected situation.
Indeed, relying on undo to make progress is intolerable UX. Not to mention that in a scene with a few thousand objects, undoing a selection is even slower than making a selection :-\
Those are indeed true affirmations, Its just a workaround.
And i agree that the 3D cursor should A: be in the undo stack, or B: should have its own undo function (i'd preffer the later but that's for an other topic)
What I meant is it would be positive to conceive other ways to achieve that corner case without losing the selection.
Absolutely. Like I said, if a solution can be found to freely manipulate the pivot point without losing the selection, that would certainly solve this. Until then however, removing the current workflow would be a regrettable downgrade.
Added subscriber: @BukeBeyond
I agree, "Active" needs to go as soon as possible. It is one of those primordial bad designs that unnecessarily complicates things, and has no place in a modern UI. It's like the right click select, or the compositor view as the editor background, or the 3D cursor that just sits there, or "Appending" a file, or calling Links, Libraries, or an "Outliner", that actually does not group, contain, or move things as it looks... Blender has so much cruft from the past.
From the user point of view, a Selection designates the Destination of a command or an edit they intent next. The Active selection introduces an unexpected Secondary selection, which most commands and edits do not need, and when they do, which is Source or the Destination is ambiguous. To the user, the word Active is what? Isn't selection active? Active most often means, a switch, like an active effect, an unmuted node, something turned On or Off, Activated, not a temporary selection followed by a command.
If Blender had multi object property editing earl on, this kind of hack design would have been unnecessary. If the compositor had a dedicated viewer area, nobody would think it is a good idea to put nodes and cables over the image you are working on.
So yes, bad designs might have temporarily solved problems when there were missing basic functions to support them early on, but they should be removed and cleaned as soon as possible to simplify future development and user experience.
This comment was removed by @BukeBeyond
Please stay on topic, for general suggestions go to devtalk.blender.org.
Some thoughts regarding removing "Active state" or making it "obvious".
In fact in many operations "active state" is not used in it "activity" meaning. It is frequently used in practical feeling "Select this first and that second". For example link data from one object to others, etc.
This is all what is really needed for many tasks with "active element".
So may be easier just to keep "selection sequence/order" somewhere with current selection? Active element then will be just "last" or "first" or not really needed at all, since all operations can be annotated with this new meaning - "Select target elements first and reference element last" or vice versa. The ability to get "selection index" for each selected element would open the whole new world possibilities for addon developers - since it will be possible to require specific order of selection for specific tasks, which is much faster than asking user to "Select this and press button 'remember source' than select that and press button 'remember target'", etc (just an example, many specific addons asking for such pre-memorization)
And it is looks like an easy feature to add. Just keep the "selection order" counter with current selection and increment on each "add" and remember in each added element current "selection order" (+api to get it back for element in selection). Like selection history in bmesh - but extended for any selection (objects, nodes, etc)
It may work not only for manual clicking, but for mass-selection too. For example in mesh edit mode user can click vertex (selection order = 1) then press "L" over mesh island (all vertex would be added to selection and they ALL should have selection order = 2) and than switch to face mode and click a quad (all 4 vertex will get selection order = 3). And we have selection with 3 "steps". In case last step is treated as "Active" - there will be 4 active elements (verts selected with quad) - and this is can be even useful, since ops can get center or choose specific vert among them or whatever.
This will give 100% strong definition of "active" and open many useful possibilities.
Dear Brecht, my other criticisms are indeed relevant to this topic. If the clipboard was capable of vectors and groups of properties, the secondary "Active" selection for most data transfer operations would be unnecessary.
Sometimes, we must trace the reasons for a convoluted design, and find that it is the side effect of some other modern UI function missing, just like when you pointed out that properties should be multi editable.
My harsh criticism comes from the respect and love I have for Blender. 3D programs are often notorious for bad UI, because it is still a primordial and unsettled field in computer science. Overall, I still think Blender is the best in the industry.
To be directly on the subject, the proposition here is a good solution for the time being. In Python, an object must be made Active specifically from a selection operator, followed by an operator that needs Active, like Join:
Note, how a programmer new to the API, has to learn about View Layers to complete the Join operation, highly unrelated to the task at hand.
The programmer will always have to worry about what object is being joined into what, because the operation will have completely different results depending on it. Using the active object for this seems completely logical and intuitive to me. As for the unwieldiness of setting the active object, that is addressed by operator context overriding elegantly and successfully.
As Brecht already mentioned, it's not possible or necessary to fully remove the concept of active/selected, just make it not be in the way when it's not needed. I think we should re-focus. Here are my takes on what have been said:
Not all methods or commands take a single argument. Some need a destination, and a source or even more. So for the internal API, operators should support this. However, when it comes to the UI, most operations are in the form of select destination, and give a command (left select, right command menu, or a key). If a special command needs more, it is the job of the UI provide this to the API, and probably better present a dropdown for further object selection.
What is not right, is that the UI should not show rare accommodations when they are not used most of the time, the active selection, the cursor, etc. This kind of bad design is now shaking the foundations of the API. Again, what does View Layers have to do with Joining a Mesh?
Imagine when painting, there always showed a clone source, even when you are not clone painting. That is what this active selection is like.
I agree with you there Mets (all of what you mentioned).
The only moment I think active shouldn't exist is when nothing is selected, but whenever something is selected there should be something active, that's my problem with the active/selected because I feel that the having an unselected object active is what makes this whole thing a problem. And also in rigs often you have an selected bone active and a deselected bone active at the same time.... bug ? maybe ? do i know how to reproduce it exactly? no. does it happen often? yes.
In the other hand what you said about
"What if we allowed hidden objects to be selected but this would reveal them in the 3D viewport to some capacity - perhaps only their outline, or with transparency, or both?"
I dont think its rare or even wild, I think the selection in the outliner and viewport should be consistent and objects should be able to be selected while non visible in the viewport anyways, heck they should be able to be active and selected even if in the viewport they arent visible, that would make selection even more "predictable" as right now when you turn off visibility of an object in the viewport you lose the selection of it.
That is relatively easy to reproduce if you understand how to make an object/element the active one.
And that is really easy to explain Active Object/ Active Element is the last one you clicked on.
That is not more complicated than that.
To obtain objects/elements selected and a deselected active one, You just have to shift double click on an element.
First shift click adds clicked element to selection and make it the active one. Second click deselects it.
So, active thing = last thing you clicked on.
That should not be perturbing.
What may be disorienting is if scripts or addons are changing active item without warning user.
@zeauro It's not that simple in complex scenes, where you have objects close together, because there clicks just go through and you tend to cycle active object or deselect. It's very uncomfortable behavior, though I think this is more towards how selection is handled.
Added subscriber: @RedMser
Added subscriber: @Tabra
I issued the feature request https://blender.community/c/rightclickselect/rmhbbc/ which I think solves the dilema without much problem.
It's about a snapping option to use origins' objects, and then using the 3d cursor like explained in there.
Added subscriber: @1D_Inc
The whole point of being active is being user specified.
There is no place for random, otherwise you will never know if your active object was actually specified by you.
Because there is no user specified active one.
Box selecting is non-picking type of a selection. You don't need active on a purpose when perform non-picking selection types.
So as a result we can't deselect everything completely, or we will lose active object on every single deselect.
This concept is useful for CAD systems, where all the properties of objects are equal, but it is not useful for objects with complex properties, like names, mesh data, materials or modifiers to display, link and propagate from Active to Selected.
Yes, the ability to loose the Active object was applied to Exclude from View layer Restriction toggle option (EC RTO) - it turns to a selected object from the active one and is confusing in practice.
There is also a naming issue - when you make a selection you get "selected objects", since they are seleted so, basically we get
Selected objects = Active objects + Selected objects
which is quite recursive terminology, so during conversations with local developers who are not familiar with Blender we prefer to call "selected objects" as "passive objects" to clarify the context when setting scripting tasks.
(We have a lot of scripts that utilizes Active - Selected paradigm due to its flexibility)
We are familiar with such an issues, but their impact was so negligible, so they didn't cause any serious workflow problems.
For example, retrieving active 3d object can be done quickly with tab / tab / combination (enter editmode, enter isolation mode, exit edit mode, exit isolation mode) in 2.7x, turned to a bit less effective tab / tab A / combination in 2.8+.
We didn't even bother to solve this problem with one-line addons like
bpy.context.scene.objects.active.select = Trueorbpy.context.view_layer.objects.active.select_set(True)because of a low priority.For bones - you never have a practical need for editing a properties of an unselected bone, and so one.
tabb.mp4
So we never saw them as a huge problems to be solved, they was way more like tiny known issues.
Undoable 3D cursor don't have much sense, since you always need its the most recent location to perform operation, and the ability to restore complex selection via undo after setting 3D cursor.
It 3d cursor will be undoable it will be hard to define if its location is the most rescent, or if it was changed during some undo set.
3dcursor.mp4
The ability to edit properties of active object (like modifiers) without selection is needed to check its appearance without influence of a selection highlighting.
Removed subscriber: @SimonThommes
Joining objects, especially taking into account joining to objects which have instances (linked data object) - very well known maya and max limitation.
JOIN.mp4
Knife project also was built utilizing Active object paradigm.
Speaking of knife project, we scripted an inverse knife project (map cut tool), that cuts selected objects with active one - with cycling through every active+single selected pair.
This allow to cut out a part of a complex compositions, that consists from several objects, like general plans, without entering an extremely expensive multiedit mode.
MAP_CUT_DEMO.mp4
We are using both regular knife project and inverse knife project for different purposes.
To cut out even more massive objects (for example, Palmyra satellite photogrammetry) we made a hack, that allow to not to enter edit mode at all, otherwise it just take eternity to process or even overflows RAM.
Active object paradigm allow those functions be a single button functions, providing all the necessary context set in dynamic context (directly in viewport), not in static context (avoiding long lists of names, for example like in 3dsmax, which was built around homogeneous system like Brecht proposed ).
There are other known workflow limitations that Multiedit also has (working with instances, etc).
Therefore, multiedit is a nice feature to have, but nothing more - it is useful when it is useful, and useless when it is useless (a definition of a workflow limitation).
Added subscriber: @finirpar
In my opinion the point of an Active system is to provide a single uniform behaviour across Blender to avoid local behaviour fragmentation across its tools like it is made in other programs.
Removed subscriber: @MadMinstrel
I agree. Active system is a system that unifies behaviour of a different tools utilizing dynamic context.
This tread is interesting by its attitude to a problems.
There is a system, that works for 97% and has 3% known issues, that are possible to solve with a single line of code.
This 3% are revieved like they are forming a system that consists from 100% issues and is completely corrupted, so the only way to solve it is to remove it and replace with industry standard solutions.
Meanwhile, industry standard solutions:
Maya: link to the first selected, parent to last selected, joining to instance crush the instance, so the abscense of a unified system makes using it a completely messy. Maya system: 50/50
3dsmax: homegenous system, static context realization with all those long lists of names in local gui or outliner, or separate local dynamic context realizations to simulate the active one, the pain from using which is not possible to explain to people who didnt used both realizations for a wide range of a workflows for a decade. 50/50
So we got a system 97/3, which 3% issues are reviewed as a system with 100% issues, that determines its change to some 50/50 system.
And this happens almost with every Blender system that don't look or behave like a similar system described in Autodesk manuals.
This seems like it could easily cause more problems than it solves.
There are many logical issues with this, when I try to think up comprehensive solutions to these, they end up being quite involved.
Predictability
For example, if you box select - activating the selected item closest to where the cursor ends makes some sense, if you box-de-select though (which may de-select the active object), re-activating based on the cursor could be confusing as the newly activated object may not be very near the cursor.
Selection operations from menu items could also behave unpredictably - the cursor location will depend on the menu item, so in those cases it probably shouldn't be used, yet - we might still want to avoid picking an item outside the view-port (for example)... alternatives exist but they all seem fairly arbitrary / weak (closest to 3D cursor, view center... etc).
It's also worth considering predictability: box selecting a few items might result in a different item being active depending on the cursor location, which could make following simple steps confusing "box-select 3 objects and join them" might have completely different results based on a subtle difference in cursor placement.
The steps to select and join become more complex to explain if the outcome isn't predictable:
Modal Operators
There is a question of modal selection operators, are they expected to enforce this rule every redraw? or only once they have finished running?
Circle select is another example where the ideal behavior isn't obvious, for consistency activating the item closest to where the cursor last selected makes most sense, this would probably need be be postponed though, to avoid a flickering UI for every circle-select update.
If there is a selection operation from nothing having been selected, perhaps it should activate something at the start of selecting too, although this means circle select would set the active object twice (temporarily showing some objects settings that get replaced with another once the operation finishes).
Non-Viewport Selection Operations
Selection operations don't necessarily happen from the view-port, they might happen.
Any of these actions would have to fall-back to some basic method of picking an active object which is likely to feel arbitrary.
Further, there are selection operations inside the viewport that don't lend themselves to "picking" an object (using mouse cursor location).
Where automatically setting active is likely not to be meaningful.
In the case of select random, consider how the properties could flicker the entire interface while adjusting sliders. Unlike circle-select (where this can be worked around), I don't think this is avoidable without much larger changes to how select-random works.
Minor Usability Issues
Since Blender's UI shows properties from the active object, I have a concern this will draws users attention to details as they work in a way that could be disruptive / distracting.
Object Modes
With objects supporting their own mode settings, there is the question of what to do if an object is in a mode (an armature in pose-mode for example).
Since it's not reasonable that automatically setting active-object enters that objects mode, there is a conflict where we might want to exit it's mode (and set it active)
yet this could be part of another scene which is in vertex-paint mode (for e.g.). Maybe it can be skipped - although it's possible their are no alternatives.
It may be these details miss the big picture, that larger reworkings of object-modes can address problems with the situation described above.
In that case though, it increases the scope of the proposal significantly.
NOTE: for the code quest we looked into bigger changes to object modes (linking them to the work-spaces for example), but ended up mostly rolling back these changes. Large changes to how object-modes are handled seems like a project that should be proposed an handled separately.
Added subscriber: @Harley
My thoughts on this are hard to explain well. Probably best described as wanting “Looser binding of Active and Selected”
I agree that “none of selected are active” is a problem, but I find that this is a symptom of a malfunctioning design and that the proposed solution actually robs of us of what the current design was attempting to do (but failing at).
The only reason we have the current design is so that we can do many-to-one, and one-to-any actions. Like parenting a number of items to one item. Or copying some attribute from one to a number of others But our design is faulty in that we don’t adequately communicate to users that we work on two distinct things: a list of Selected items plus a single Active item. The Active item is not really Selected in an intention way, but we then show them to users so that they all seem similar.
The proposed solution breaks this wonky design a bit. If a group of selected items always contains an active one then that means that “active” just becomes the equivalent of “super-selected”, a single item that is somehow special among the other selected. But since it is also selected these “one-to-many” and “many-to-one” operations are a bit worse. It is no longer “copy attribute from Selected to Active” but “copy attribute from the Active Selected to the non-active Selected”.
The first problem is the naming. Items that are “Selected” make sense to everyone. But what is an “Active” item? Do we have “inactive” items? I guess “inactive” items might be things that are not selectable? Items that are not currently enabled? These don’t relate to our current use of “Active” though, because “Active” is a bad descriptor for this use.
If I could rename the “Active item” it would be “Action item”. And then I would make it a list. Right now operations work on a list of Selected plus the one Active. I’d make this two lists of items: one of Selected (zero or more items), and another of Action (zero or more items).
For users “Selected” would just be the items that are marked as “Selected”, as in being marked as special by being brighter, having a highlight outline, etc. But “Action” would not. Action items are never shown in some special way. Indicating an Action item does not, in itself, make it Selected.
Sounds weird compared to our current design, but let’s get to some examples. User selects 10 items, and they all become “Selected” and show as selected. User then indicates that an item outside this list is to be acted upon. Typically, this would be right-click on it, then selecting an action from a context menu. They then select “Add to selection”. In this case we have a list of “Selected”, and a single “Action” item and the operation moves the indicated into the selection list.
In a familiar usage example, you select 10 items, then right-click on any item (selected or not) and then choose “Parent” from the menu. You are now able to parent any list of items to any item, regardless of selected status.
Carefully select a subset of your mesh objects, by shift-clicking on the ones you want. Now do something different: right-click on an (unselected) camera and select “Make Active”. Doing so did not change your selection list, so continue working…
Active item (or the "Main" element among the selected, like a general among the soldiers) is that one which was activated by picking. All other objects are inactive, independently if they are selected or not.
If Action items is not shown there is no ability to make sure visually which object is actually activated. Such a concept will be ruined by the very first complex scene.
First, not all users use right click menu. For example, we are using RMB as viewport pan to meet relevancy requirements.
Viewport navigation is always more relevant than any kind of menus, the default Blender scroll actions for viewport rotate and zoom is a wise choice - a nice example of a design based on relevancy.
Pan on RMB brings the entire navigation to mouse so it require just single hand, and make it compatible with tablets as well, so it is more versatile than default Shift+MMB.
Second, context menu action require clean object accessibility, which will be also ruined by complex constructive scenes.
This action is completely implicit. Also, you will have to provide all the possible action in a menu, which will make it long, especially if to take into account addons.
If you have to do something carefully, that means that you walk on a minefield provided by design.
Every single action that has been designed to be performed with care will be burned at the very first deadline.
That's why there is no such a term as "Careful" in a workflow design.
Blender used to be a deadline-proof software because was designed avoiding careful actions.
Check up operational speed (parenting, joining, knife project, linking object data, spreading selected across instances of active, etc), every single action is explicit and confident, due to proper Active object paradigm.
ACTIVE SPEED.mp4
That's the speed of a dynamic context.
From reading this I am wondering. So generally there are 3 different ways of how an operation is targeting elements:
For the first 2 it's necessary to have an Active Element and the user always want's to be in control over what element is active.
So I agree with @ideasman42 that this shouldn't constantly change. The active should ideally stay active unless manually changed by Shift selecting.
@Harley Right clicking to use a menu would make it too unpredictable what element the operation will run on so I'd still prefer if this happens by selecting and visually showing first what has become active.
The unpredictability usually comes from the first 2 if the active item is not selected.
So if we generally want to be in absolute control over the active element and don't want to do operations that rely on an active element that we can't predict (because it's not selected), then how about these operations can only be executed if the active element is also selected.
In practice, if you have multiple objects selected and none of them are active and you want to go into edit mode, it will instead give you a message "No active element selected".
Same thing for parenting, linking or transferring data, etc.
In all of the examples shown where the active element is relevant for operations from the relevant main editor (3d viewport, dopesheet, uv editor) the active element is selected first or last intentionally to set it as active.
We are conditioned to already do this, and I don't see a strong reason for this to change.
For the use case of showing the properties in the properties editor of an unselected active element, this can still be possible then.
The active element doesn't become un-active if it's unselected.
But all the operators that would cause confusion (Many to one & One to mnay) would just require you to ahve an active selected element.
@1D_Inc are there any operations where this behaviour would make things more difficult?
The operational point of Active system is to allow quickly set a simple temporal operational hierarchy in dynamic context (directly, visually, without using names).
I would like to place it in the other order and also expand the list:
One to many - Hierarchical actions, the General gives orders to the soldiers .
Examples - all data linking actions, parenting, transform by active pivot point actions, etc.
Script examples - distribute the selected objects among the instances of the Active object, distribute the name of the Active object among the selected ones.
Many to one - Hierarchical actions, the General retrieves data from soldiers.
Examples - joining, baking, 2.7 knife project etc.
Script example - a script that sends all the materials of a selected objects to the active one, that allow to overview all the materials used in selected objects at once, forming temporal local library. This allow to count them, check them, search which exact object some suspicious material belongs to, copypaste such a library to a different file by copying the active object if needed, etc.
All selected - Non-heirarchical (homogeneous) actions, General is not needed.
Examples - Multiedit, Grabbing, non-active pivot transformations, etc.
Script example - select all instances of all selected objects, filter out non-instances from selection.
Only Active - Non-herarchical actions, single object - no hierarchy.
Examples - properties editor display, entering editing modes, including giving a context for available editing modes - all modes except Object mode. Since Multiedit was added, they are presented with Sculpt mode, Vertex paint and other similar modes - so now they are all modes except Object mode and Edit mode.
Yes, since they are hierarchical.
Yes, deselected Active + selected objects case.
The problem this solution is trying to solve was available before, the multi-edit feature only exacerbated it, since multi-edit is a product of a homogeneous systems (where all selected objects has equal status) that contradicts hierarchical systems (to which the Active object paradigm belongs) on a concept level.
Therefore, it is not easy to reconcile them with each other, and there will be no perfect versatile intuitive solution.
At the moment there are unpleasant issues, but they are not critical in my opinion. I mean the whole system is workable if you are already familiar with its behaviour, it is just not looking good since it contains features that originally conflicted with each other because of a different design origins.
Lesser discoverability raises the entry threshold bar a bit.
Indeed, we can try to solve nicely the most relevant cases, or at least try to not to add critical issues.
Yes, keeping the Active is important, since it is needed when it is defined by user on purpose.
The proposed blocking message behaviour can make things more clear, at least for beginners, but any kind of blocking messages are quite oppressive.
It is hard to remember using such kind of a blocking messages for any relevant actions, Blender somehow managed to successfully bypass them by design.
I can see the problem with blocking message for deselected Active + selected objects case - the message will be shown for linking, parenting, etc, but there will be no ability to retrieve stored Active one, since such a message will be shown for the edit mode as well (I mean isolation mode trick https://developer.blender.org/T82359#1179165).
That will form the strong necessity for "Add deselected Active to selection" script or function.
Possible solution is to retrieve the deselected Active while exiting edit mode, forming "everything that was in edit mode became selected" rule.
Pros
Cons
The situation with the only Active but deselected case is actually controversial.
According to my proposals it will be annoyingly reselected, according to your proposal its edit modes should be blocked with a message until it is manually re-selected, or will contradict deselected Active + selected objects case behaviour.
That's my thoughts.
Any core hierarchical systems are difficult to design and analyze because there are always many dependencies, I hope my thoughts on this are clear and helpful.
Things can get more interesting if to assume that switching to edit mode can have Tab autoselect feature instead of "everything that was in edit mode became selected" rule.
This way it could be possible to retrieve deselected Active one if it is needed. Maybe such a solution will allow to avoid using blocking messages, except cases when there are no active and only selected ("Active object is not set" message) or active is not editable ("Active object is not editable" message) to explain why tab does not bring edit mode in that cases.
Issues I can see there, briefly:
Anyway, this looks like a concept with good potential and is probably worth discussing or thinking through.
Removed subscriber: @Tabra
Lets take a look at “active element” problem from another angle. It needed for some specific set of operations (not all and not even majority) and most of the time it main purpuse - just distinguish one element among set of others.
This is essentially a “Mark”, not a element “State” (as selection). So... why not just make a “item marker” TOOL? It will simplyfy everything greatly without loosing any bit of possibility! let me explain.
Blender already has “marker tool” which is not universal, but greatly helpful for a set of operations. I’m speaking of 3D Cursor. It essentially marks a point in 3D-space. and all other operations that need “marked point in space” just use it. And UI-wise - its a tool that just places a mark with a clear set of “how to do that fast” rules
So why not have another tool for placing mark not in 3D-space, but in “items list” “space”? User just may select this tool and click in viewport on object, vertex, whatever, or click in outliner on any item here or click on a modifier in stack, etc - and boom! you get “green checkmark” near item (if tool active) and it is clearly active regardless of object type. And all operations that need “active element” know where to get it. and can clearly communicate any problems without shady “selection order”
The tool even may have “tool options” that will never confuse user since for tool they may perfect sence. Want last element in fresh selection automatically marked active? no problem, checkbox. want auto-“deactivation” if element gets hidden? no problem, checkbox, you decide. Mark changes also can be recorded in undo history, etc, etc.
AFAIK there is really no use cases where user need “several marks” in different “items list”, which is confusing in current implementation. so treating “active” as a state is a bit of overdoung things. its just happened that it is easier to implement as some sort of “state”, but this is really a “mark”, a scene attribute pointing on arbitrary item
It is heavily workflow-dependent.
In creative workflows the active operations may be not used much.
In constructive workflows they are used all the time.
This will increase infrastructure complexity at the cost of much lower operational speed and lack of a solution to the original problem - deselected active + selected objects case.
There are no actual problems with setting an active object in Blender.
I probably should provide a proper clarification of static and dynamic contexts types in context of a system design.
Since I have used the terms of Static and Dynamic contexts in the past without much clarification I should probably provide a proper definition of static and dynamic context types in the context of system design.
The difference between those contexts is about how exactly data is handled.
Static context is about handling objects with its names (the context is represented by name).
For example, when you hide objects in static context, you need "to hide Trees, Grass, Fences and Cars".
The static context is strategic.
It allow to handle a bigger capacity at lower workflow speed - the same way works HDD.
Dynamic context is about direct and visual objects handling (the context is represented by objects itself).
For example, when you hide objects in dynamic context, you need "to hide that particular unnamed subset of objects that cover an object you would like to edit, then unhide them to check the composition after editing, and hide another subset of objects that covers your edited objects from the other side".
The Dynamic context is tactical.
It allow to handle lots of low capacity temporal cases at higher workflow speed - the same way works RAM.
If you are familiar with addons like Booltools or Boxcutter, it is quite exact to describe them as "dynamic context realizations of a static context Boolean modifier."
I think I have to try to explain it, since explanation will contain important system design information.
Alongside with multiedit there is another homogeneous system that contradicts hierarchical Active object paradigm - a box selection set by default.
Box select doesnot correspond to the Active object paradigm, since it is an attribute of a homogenious systems - in software like autocad (which also contain multiedit), 3dsmax, or Inkscape it fits pretty well.
I will pick 3dsmax as it is industry standards anchestor, and I think that I have to post some 3dsmax videos for proper explanation.
It is important that I do not propose anything from those videos and use them only for system comparisons, so I guess that I can post them here.
Let's take a look at this video about selections in 3dsmax. It is quite close to the system we got since redesign, so I guess that such a behaviour was the goal.
https://youtu.be/Y_eHi0Az4CI
When you start using 3dsmax from box selection, its picking action has no any additional meaning except just adding objects to a selection - as a result it covers it all. A system is completely predictable as it is homogeneous - there is nothing else to discover.
When you start using Blender from box selection - its picking action is essential in context of active object paradigm, which is more superior than the box selection itself.
In general, single object editing and active-selected interactions are primary since they take a lot of attention, there are lots of thing to care of, and Blender satisfies such a requirement.
Homogeneous actions takes less of attention, so they are secondary.
In Active object paradigm selecting active by picking and then expanding selection with non-picking action is quite common, such a behaviour better fits its paradigm.
Non-picking selection type set by default fits homogeneous systems - for example, when we use 3dsmax or Autocad we have to put up with the lack of advantages inherent in the active object paradigm, but it is okay to have box selection by default in such a homogeneous systems.
In a system that require picking actions, setting a non-picking selecting action by default is quite questionable.
Let's take a look at this addon video, ignoring its UI realization - industry standards was never properly designed to expand,
so you have to put your addons in such kind of a flying panels that hovers viewport - it is a well known industry standard issue.
Let's take a look at its functional realization, which is quite similar to the Blender's Booltools addon.
https://www.youtube.com/watch?v=Tv6Uh0BzpPA&feature=youtu.be
Because of an abscense of an Active object paradigm in 3dsmax for such kind of behaviour you have to provide object pickers, selection set holders, static context list selectors and other similar stuff, which makes operands implicit and hard to set.
It is also a problem that you have to supply every tool with such a functionality to define operands, since homogeneous systems does not suppose any differentiation between selected object.
Static context is not supported properly there as well, a naming convention in 3dsmax don't even represent an individual objects.
Unlike Blender preemptive (displacing?) objects naming (naming with .001 .002 suffixes) all objects in a 3dsmax scene can share a single name, for example - a "Wheel", which cause collisions for list selections, such as selections in outliner.
So realizations of a similar systems in 3dsmax cause double problems.
In contrary, Booltools has no problems with setting operands - it is completely clean and explicit due to Active object paradigm that unifies all similar behaviour across the program.
The same is true about recent knife project redesign, which, as a hierarchical tool that utilizes Active object paradigm, got into the conflict zone between hierarchical Active object paradigm and homogeneous multiedit.
It was put out of an active object hierarchical paradigm and switched to homogeneous realization - with static context selection from outliner and annoying preparations before operation - in such a realization such a tool is suitable for homogeneous environment, like in 3dsmax, autocad or Inkscape.
If you think that it is clunky and heavily discoverable (as was shown in blender today video ) - in 3dsmax everything similar is made just like that.
So, during system design it is important to take into account that
Campbell Barton made a very deep research about possible active object solutions in context of a non-picking selection types.
What he discovered is a system level incompatibility.
I am trying to explain that the origin of this incompatibility is mixing systems with different design origins - hierarchical Active object paradigm and homogeneous non-picking selection types.
To further explain why Blender’s design is superior, here is a crash course of the system’s design history in CG
In the end of 70`s AutoCAD was born.
To support lots of objects with simple properties (called primitives edited directly with no dedicated edit modes) and no intendent complex interaction behaviour it was built around primitive Homogeneous paradigm, which is suitable for drafting in the best way. In Homogeneous paradigm every object in a selection has equal status, so this allowed to design homogeneous-related interaction systems, like box selection by default and Multiedit as well, covering all drafting demands of the time.
A GIF:
**In the end of 80
s 3Dsmax was born, as 3dstudio for DOS.** It was built in tight connection with supporting AutoCAD technologies, and also was supposed to be used for for architectural purpose ([3dstidio VIZ ]] by Kinetix release in [[ https:*www.itweek.ru/industrial/article/detail.php?ID=48290 | late 90s ](https:*www.buildings.com/articles/37415/autodesk-introduces-viz-4)) so it inherited lots of a system design, suitable for homogeneous paradigm like box selection. 3Dsmax and AutoCAD became popular and widespread such a paradigm in the industry, every program like Maya was inheriting them with negligible enhancements.In 1994 Blender was born.
Instead of a primitive Homogeneous system it presented simple Hierarchical system (Active object paradigm).
It is an evolutionary change in comparison to Homogeneous systems, which allowed complex object properties and solved/unified interaction behaviour across the program at a very affordable workflow cost.
In Active object system you pick Active object by picking action (the most relevant action), and then expand your selection on demand with non-picking actions, such as
If you need to perform a hierarchical action, you set the Active object. If you need to perform a homogeneous action - you don't set the Active object.
Easy to learn, easy to use.
In overall, system looks like this:
In 2018 was an attempt to bring several popular Homogeneous systems, bypassing Active Object paradigm Blender was designed around, like Multiedit and box selection by default, right from 80`s AutoCAD.
So, when you try to make something like this by default
the system experiences a predictable and strong torque that destroys the overall design.
That's why, for example, tweak by default that sets active object with its picking action represents Hierarchical Active object paradigm systems better than box selection by default which is more suitable for Homogeneous systems with no Active object paradigm.
Added subscriber: @AndyCuccaro
Added subscriber: @KevinCBurke
I agree. From my own experience and the multitude of 'active' vs. 'selected' bug reports, this is confusing and limiting when editing multiple objects. It creates issues in situations like editing F-Curves in the Graph Editor where a user cannot activate multiple keyframes with a Box Select. Here's a screencast demonstrating this:
I agree and vote for the 'active' object being the last object in the selection. In a Box Select, it would be the object closest to the mouse on release. Even if some functionality of 'one to many' or 'many to one' is lost (not sure that it has to be), I feel that that is much better than the confusion and frustration of not having an active object.
When editing multiple properties, the user sees a distinction by color that they are editing multiple objects. The last object in the selection (whose values are shown in the UI) would be highlighted in a different color.
It seems like the default box select has confused a lot.
It's poorly designed, including the graph editor.
In graph editor list box selection behaviour differs from curve box selection and keyframes box selection, so
Also, picking selection is still horrible in graph editor, it is imperative to be extremely precise for some reason (taking into account Blender restored awesome mesh vertices selection which is a nice UX example of how to select tiny dots on screen).
This UX design is anything but unified, and it doesnot represent overall active object paradigm at the system level, no wonder people experience problems.
Added subscriber: @AlexeyAdamitsky
Added subscriber: @Slowwkidd
I recently encountered an annoyance related to this: I have a file with many kitbash assets of buildings, and every building is made of multiple separate objects. For many reasons, I needed to join the separated objects in order to have every building as one object. This process was quite tedious, because whenever I was box selecting in the 3D viewport various objects to join, I couldn't because of an object I selected before, which became active, but wasn't part of the box selection I made. So every time I needed to first click an object that would have been part of the box selection in order to then select and join. As you can imagine, in a large file with hundreds of different objects, this process slows down a lot a task that should be fast and simple. I didn't read every single post on this task, so I apologize if my case is something that was already brought up, but I hope this issue can be considered and this task continued to be tackled.
Added subscriber: @ChristiaanMoleman