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.

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:

1. you click object: its selected and made active.
2. you click outside, object is deselected and the object stops being active.
3. you select a group with box/lasso/circle, the closest to the mouse cursor at the end of the selection gets to be the active object.
4. you shift click a non active object that is within the selection: It should be deselected. ( because most of the times you dont want to make one more object the active, you just want to deselect one object from the selection )
5. you shift click a new object into the selection it should be added and become active.

@Luciano Muñoz Sessarego (looch)
I strongly agree. The list you outlines should be the case for all "things" and not just objects.
Especially with the behavior of T54862 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?

@Demeter Dzadik (Mets)

it's just not indicated at all.

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.

@Luciano Muñoz Sessarego (looch)
I strongly agree. The list you outlines should be the case for all "things" and not just objects.
Especially with the behavior of T54862 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).

Yes I agree, this one seems to be the more "predictable" one for the user out of the options I've tested.
In <<other competitor softwares>> it feels kind of random for me when you do such type of selection, but it hasn't bothered me at all.

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.

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

Maybe there's a clever solution to avoid that instead of having to use the pinning icon more often?

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

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.

• which is the case on armatures. Interestingly enough sometimes you can have an active object that isnt selected that looks selected...or 0 selected objects none of them showing any signs of selection but still having one active.

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.

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 T82359 in the context of hidden bones in pose mode.

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

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.

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:

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

2. 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":

1. Check global position of last known active element for current mode, and activate closest to it
2. In case there is no last known position - activate closest to 3D cursor

In T82359#1060426, @ronan ducluzeau (zeauro) wrote:

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

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.

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?

In T82359#1060822, @Ilja Razinkov (IPv6) wrote:

Choice based on closest to mouse position would not be great decision though, imho... mouse position is generally random, this will feel mostly broken.

This depends on which selection method is used. With circle select, mouse position is far from random. With 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.

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

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.

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

I don't know if this is a good idea. In any case an add-on developer can already do this.

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

I agree.

In T82359#1061962, @Sybren A. Stüvel (sybren) wrote:

In T82359#1060426, @ronan ducluzeau (zeauro) wrote:

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.

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?

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

In T82359#1061962, @Sybren A. Stüvel (sybren) wrote:

On the other hand, it does present something predictable, as artists generally know where their mouse is.

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.

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?

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.

@Luciano Muñoz Sessarego (looch) 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.

In T82359#1079078, @Luciano Muñoz Sessarego (looch) wrote:

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?

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" <<bug>> 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.

@Luciano Muñoz Sessarego (looch): 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.

In T82359#1050426, @Brecht Van Lommel (brecht) wrote:

I think the long term solution here is to remove the concept of "active" for the most part, and have multi-object properties editing (T54862) everywhere instead.

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.

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.

In T82359#1098595, @Brecht Van Lommel (brecht) wrote:

Please stay on topic, for general suggestions go to devtalk.blender.org.

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:

l = bpy.context.selected_objects

for e in l:

  bpy.context.view_layer.objects.active = e

  bpy.ops.object.select_grouped(type='CHILDREN')
  if bpy.context.selected_objects:

    bpy.context.view_layer.objects.active = bpy.context.selected_objects[0] # << this can be automatic

    bpy.ops.object.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:

• Making multi-object properties editing default sounds great. I'd love to see the designs in T54862 implemented as an experimental feature, since it could potentially be a massive workflow break for literally all users if it is anything less than a pure improvement over what we have now. I think this would address Problem #1.
• Selecting hidden objects in the outliner in order to modify them in the Properties editor is something I do *constantly*. I could not live without it. Currently this is only possible because hidden objects are allowed to be active, which is great. Just wanted to point that out, as I think it's important to consider when tackling Problem #2.
• A very shy suggestion I'd have as to tackling problem #2 is a pretty wild one: 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?

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.

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.

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.

@ronan ducluzeau (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.

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.

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.

1. If there are Selected things, there is always one of those that is the Active thing.

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.

There are Selected things, but none of them is Active: a sidebar/numerical/properties panel will not show information, and generally be empty without explanation why.

Because there is no user specified active one.

box-selecting multiple things at the same time.

Box selecting is non-picking type of a selection. You don't need active on a purpose when perform non-picking selection types.

2. If a thing is Active, it is also always Selected.

So as a result we can't deselect everything completely, or we will lose active object on every single deselect.

In T82359#1050426, @Brecht Van Lommel (brecht) wrote:

multi-object properties editing

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.

In T82359#1047270, @Julien Kaspar (JulienKaspar) wrote:

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.

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 = True or bpy.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.

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.

The ability to edit properties of active object (like modifiers) without selection is needed to check its appearance without influence of a selection highlighting.

In T82359#1050428, @Luciano Muñoz Sessarego (looch) wrote:

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?

Joining objects, especially taking into account joining to objects which have instances (linked data object) - very well known maya and max limitation.

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.

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

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.

In T82359#1211924, @fin (finirpar) wrote:

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.

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.

If there are Selected things, there is always one of those that is the Active thing.

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:

• Box select # items.
• Shift-Click on "SomeName" to make it active.
• ... unless it happened to be near the cursor, in that case don't.

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.

• From the outliner.
• From the dope-sheet.
• From loading operations (import/append).
• From changing context (switching to a scene for example, which may not have the same objects from when it was last used).

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

• Invert Selection
• All by Type
• Random
• Pattern

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.

• Overall, increased flickering UI changing based on changes to selection.
• In the outliner you may want to quickly check how a scene looks without an object. Currently you can quickly toggle it on and off using the eye-icon. If this would set another object active, the current materials, nodes etc may change in a way that's disruptive.
• It can be useful to invert the selection - perform an operation, then invert the selection back (I would assume changing the active object would leave me with a different active object).
• Setting the active object it's self could have different outcomes, especially with heavy scenes.
  
  An object may have heavy materials, using textures that need to be loaded into memory, so box selecting to delete for example, could begin displaying heavy information based on the object that happened to be set active. Ideally showing a material should not be lagging too much, nevertheless, this kind of minor annoyance seems likely from time to time in practice.

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.

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…

In T82359#1219648, @Harley Acheson (harley) wrote:

But what is an “Active” item? Do we have “inactive” items?

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.

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.

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.

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.

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.

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.

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.

Carefully select a subset of your mesh objects, by shift-clicking on the ones you want.

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.

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:

1. Many to one
2. One to many
3. All selected

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 @Campbell Barton (campbellbarton) that this shouldn't constantly change. The active should ideally stay active unless manually changed by Shift selecting.
@Harley Acheson (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.

@Paul Kotelevets (1D_Inc) are there any operations where this behaviour would make things more difficult?

In T82359#1219861, @Julien Kaspar (JulienKaspar) wrote:

From reading this I am wondering. So generally there are 3 different ways of how an operation is targeting elements:

1. Many to one
2. One to many
3. All selected

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:

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

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

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

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

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.

Yes, since they are hierarchical.

The unpredictability usually comes from the first 2 if the active item is not selected.

Yes, deselected Active + selected objects case.

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.

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.

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.

Yes, keeping the Active is important, since it is needed when it is defined by user on purpose.

But all the operators that would cause confusion (Many to one & One to mnay) would just require you to ahve an active selected element.

@Paul Kotelevets (1D_Inc) are there any operations where this behaviour would make things more difficult?

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

• Retrieving deselected Active object has never been easier.
  
  Cons
• Entering edit mode action turns to a exclusive action without a blocking message. A bit less uniform behaviour.
• This could work only for editable Active objects, which is an unpleasant limitation even for isolation mode trick, even if such cases are in most.
• The situation with only Active in selection is not clear - it is useful to edit single deselected active object, for example for tweaking geometry in edit mode and checking its appearance in object mode with modifiers, or for vertex paint to see user-defined wireframe instead of highlighted.

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:

• Heavyweight selection lags just to make active selected.
• Only Active but deselected case may require additional design (for example, making tweaks to overlays, or making Tab autoselect feature optional)
• I don`t know if there are plans to expand multiedit to other editing modes, this can have some influence.

Anyway, this looks like a concept with good potential and is probably worth discussing or thinking through.

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

In T82359#1221304, @Ilja Razinkov (IPv6) wrote:

It needed for some specific set of operations (not all and not even majority)

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 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!

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

In T82359#1218707, @Paul Kotelevets (1D_Inc) wrote:

• 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

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

• Any hierarchical system realization is questionable from the point of view of a homogeneous system - and vice versa - any homogeneous system realization is questionable from the point of view of a hierarchical system.

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 late 90`s) 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

• A (select all)
• B (box selection)
• C (circle selection)
• and lasso.

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.

In T82359, @Sybren A. Stüvel (sybren) wrote:

1. Is there an agreement that the current situation causes issues, and that having a stronger correlation between Active and Selected is a good thing?

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:

In T82359, @Sybren A. Stüvel (sybren) wrote:

2. Is there an agreement that the proposed two rules are the way to go?

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.

In T82359, @Sybren A. Stüvel (sybren) wrote:

How do we implement these rules in a way that makes sense to artists?

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

• in list selection case is sets active object as first picked by box selection, so it changes your active object, unless the selection is started from an empty space, and active one is not marked in the list so you have to guess which one is actually active.
• in curve selection case box selection sets the active curve to the last one from the list, so you loose user defined active curve.
• in keyframes selection case it resets the selection so it looses active selected keyframe so animators have problems described by Kevin in case if they don't use additive B to select the border, and blame the active object as a result.

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.