Review Preselection in Outliner #37430

New Issue

Jonathan Williamson · 2013-11-14T02:10:26+01:00

2013-11-14 02:10:26 +01:00

Anytime you click within an item's line, but not on the name, in the Outliner the item gets highlighted, as a preselection of sorts. This has it's uses but mostly is confusing and annoying to users.

This feature needs to be reviewed to see where it's valuable, how it could be improved, and whether or not it should stay.

Anytime you click within an item's line, but not on the name, in the Outliner the item gets highlighted, as a preselection of sorts. This has it's uses but mostly is confusing and annoying to users. This feature needs to be reviewed to see where it's valuable, how it could be improved, and whether or not it should stay.

Jonathan Williamson commented

2013-11-14 02:10:26 +01:00

Changed status to: 'Open'

Jonathan Williamson commented

2013-11-14 02:10:26 +01:00

Added subscribers: @JonathanWilliamson, @brecht

Brecht Van Lommel commented

2013-11-14 11:50:10 +01:00

This actually is a deeper problem than it seems at first. When talking about objects making the selections sync makes sense, but for other types of datablocks there is no global concept of them being selected in Blender. So this is why the outliner has its own selection, because it works for every type of data.

This design task has the potential to go too broad in rethinking the selected/active system, which I want to avoid at this point (people can make a proposal on the wiki for that if they want). There may be some simpler or intermediate solution where for every type of data that does have its own selection it is always synced (objects, bones, anything else?), but that needs some careful thought to see if it can be designed in a way that isn't too confusing.

This actually is a deeper problem than it seems at first. When talking about objects making the selections sync makes sense, but for other types of datablocks there is no global concept of them being selected in Blender. So this is why the outliner has its own selection, because it works for every type of data. This design task has the potential to go too broad in rethinking the selected/active system, which I want to avoid at this point (people can make a proposal on the wiki for that if they want). There may be some simpler or intermediate solution where for every type of data that does have its own selection it is always synced (objects, bones, anything else?), but that needs some careful thought to see if it can be designed in a way that isn't too confusing.

Jonathan Williamson commented

2013-11-14 17:27:27 +01:00

@brecht, yeah it's much more confusing than it initially seems. I think we should consider first whether anything other than objects should even be selectable in the Outliner. I'm tempted to say they should not. For example, is there any benefit to being able to select Datablocks within an object? Selection doesn't really do anything. You cannot move that datablock. You cannot directly edit by selecting it. And selecting it to make it active (in what ever way) does toggle other selected datablocks either, making it even more inconsistent.

I agree this needs a very carefully thought out proposal. I will continue mulling it over and then come back with a proposal for it.

@brecht, yeah it's much more confusing than it initially seems. I think we should consider first whether anything other than objects should even be selectable in the Outliner. I'm tempted to say they should not. For example, is there any benefit to being able to select Datablocks within an object? Selection doesn't really do anything. You cannot move that datablock. You cannot directly edit by selecting it. And selecting it to make it active (in what ever way) does toggle other selected datablocks either, making it even more inconsistent. I agree this needs a very carefully thought out proposal. I will continue mulling it over and then come back with a proposal for it.

Bartosz Moniewski commented

2013-11-22 01:46:08 +01:00

Added subscriber: @BartekMoniewski

William Reynish commented

2013-12-01 16:09:40 +01:00

Added subscriber: @billrey

William Reynish commented

2013-12-01 16:09:40 +01:00

@JonathanWilliamson:

There is a benefit to being able to select datablock items: those datablocks can then be displayed in the Properties below the Outliner. So, the user clicks the material of an object, and that material is displayed in the properties.

But that doesn't negate the issue you raised. The confusion of different selections in different editors is real an unnecessary.

Here's my proposal:

The user clicks an item in the outliner: it is selected, and the object datablock properties are displayed in the properties.
The user clicks a datablock (ie material or mesh etc) in the outliner: select the object it belongs to and display the settings for that datablock in the Properties.

@JonathanWilliamson: There is a benefit to being able to select datablock items: those datablocks can then be displayed in the Properties below the Outliner. So, the user clicks the material of an object, and that material is displayed in the properties. But that doesn't negate the issue you raised. The confusion of different selections in different editors is real an unnecessary. Here's my proposal: - The user clicks an item in the outliner: it is selected, and the object datablock properties are displayed in the properties. - The user clicks a datablock (ie material or mesh etc) in the outliner: select the object it belongs to and display the settings for that datablock in the Properties.

Simon Repp commented

2013-12-21 21:48:41 +01:00

Added subscriber: @simonrepp

Vlad Mafteiu Scai commented

2014-07-03 08:55:31 +02:00

Added subscriber: @00Ghz

Vlad Mafteiu Scai commented

2014-07-03 08:55:31 +02:00

Any updates on this?

Jonathan Williamson commented

2014-07-05 16:36:46 +02:00

@00Ghz not currently, but it's still something I hope to work on getting addressed soon.

Julian Eisel commented

2016-06-12 15:49:02 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2016-06-12 15:49:02 +02:00

Hey guys, it currently looks like the layer manager I'm working on is going to be placed in the outliner, but I'd really like to improve outliner selection before doing that. So trying to get some attention back to this task.

I'm not sure why we can't simply sync outliner selection with object selection if the selected item is an object, like Brecht said earlier? At least, I don't see enough importance in the separated selection that justifies such an un-intuitive behavior. It doesn't seem like a commonly needed feature.
If we want to keep separated selection, we alternatively could do the following:

Add button to toggle outliner/object selection syncing, similar to button in image editor for syncing UV/edit mode selection.
Add modifier key (Alt?) for un-synced selection. Not really nice but as said earlier, I don't think it's something you do a lot.
A mixture of both.
On top of that, we could add the properties editor syncing, as William proposed.

What annoys me much more is the highly inconsistent selection in the outliner though. When selecting an item it's added to the selection, whereby everywhere else in Blender, default is to deselect other items and select clicked item. Usual combinations with modifier keys don't work either.
Is that just because it has been coded like that during the 2.5 project and nobody changed since then, or are there more reasons for it?

Hey guys, it currently looks like the layer manager I'm working on is going to be placed in the outliner, but I'd really like to improve outliner selection before doing that. So trying to get some attention back to this task. I'm not sure why we can't simply sync outliner selection with object selection if the selected item is an object, like Brecht said earlier? At least, I don't see enough importance in the separated selection that justifies such an un-intuitive behavior. It doesn't seem like a commonly needed feature. If we want to keep separated selection, we alternatively could do the following: * Add button to toggle outliner/object selection syncing, similar to button in image editor for syncing UV/edit mode selection. * Add modifier key (Alt?) for un-synced selection. Not really nice but as said earlier, I don't think it's something you do a lot. * A mixture of both. On top of that, we could add the properties editor syncing, as William proposed. What annoys me much more is the highly inconsistent selection in the outliner though. When selecting an item it's added to the selection, whereby everywhere else in Blender, default is to deselect other items and select clicked item. Usual combinations with modifier keys don't work either. Is that just because it has been coded like that during the 2.5 project and nobody changed since then, or are there more reasons for it?

Brecht Van Lommel commented

2016-06-12 16:29:56 +02:00

Users manually syncing selection seems like a poor solution, we should avoid that unless there is really no better alternative.

It seem worth trying to sync selection for all data types that support it. It wouldn't necessarily involve actual syncing of the flags, two wrapper functions tselem_is_selected() and tselem_set_selected() that internally use tselem->flag or e.g. ob->flag depending on the data type might be simplest? For objects setting the selection state also needs to modify the Base though, so it's a bit more complicated probably, not sure how the layer changes will affect this.

If we want to go further and do properties editor syncing or add a selection state for more data types, it gets more complicated.

If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material?
Blender selection is more based on a hierarchy, e.g. active scene > active object > active material > active node. Would selecting in the outliner try to fit that kind of thing, so selecting a material in the outliner would make a particular object or even scene active so that the active material is shown? A material can be used by multiple objects though.
Or would selecting the material in the outliner pin the material in the properties editor? What happens if they then select an object in the 3D view, would they first have to manually unpin the material to show it, or would we change that behavior?
Or would we introduce a new global selection state, where you have a list of selected/active datablocks (or other data types)? Other 3D 3D applications often work like this rather than with hierarchical selection. This would obviously be a big change.
If you select e.g. an image datablock or sequence strip, would we show this in the properties editor? It would make sense for consistency but that's now how Blender works currently.

I don't know what the rationale was for different selection behavior in the outliner was, it predates the 2.5 project.

Users manually syncing selection seems like a poor solution, we should avoid that unless there is really no better alternative. It seem worth trying to sync selection for all data types that support it. It wouldn't necessarily involve actual syncing of the flags, two wrapper functions `tselem_is_selected()` and `tselem_set_selected()` that internally use `tselem->flag` or e.g. `ob->flag` depending on the data type might be simplest? For objects setting the selection state also needs to modify the `Base` though, so it's a bit more complicated probably, not sure how the layer changes will affect this. If we want to go further and do properties editor syncing or add a selection state for more data types, it gets more complicated. * If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material? * Blender selection is more based on a hierarchy, e.g. active scene > active object > active material > active node. Would selecting in the outliner try to fit that kind of thing, so selecting a material in the outliner would make a particular object or even scene active so that the active material is shown? A material can be used by multiple objects though. * Or would selecting the material in the outliner pin the material in the properties editor? What happens if they then select an object in the 3D view, would they first have to manually unpin the material to show it, or would we change that behavior? * Or would we introduce a new global selection state, where you have a list of selected/active datablocks (or other data types)? Other 3D 3D applications often work like this rather than with hierarchical selection. This would obviously be a big change. * If you select e.g. an image datablock or sequence strip, would we show this in the properties editor? It would make sense for consistency but that's now how Blender works currently. I don't know what the rationale was for different selection behavior in the outliner was, it predates the 2.5 project.

Julian Eisel commented

2016-06-12 18:13:37 +02:00

I'm going to look into the selection syncing in the coming days, had something similar in mind as @brecht wrote.
Currently getting the base works using BKE_scene_base_find which uses slow listbase lookup. Could use a hash table, but not sure it's worth the extra memory. With the new layer system we could only iterate over the layers the object is in (object layers store a Base * array in current implementation).
Anyway, just brainstorming about alternatives, I don't see a big urgency in changing.

Will also look into making element selection consistent, this is actually more of an issue for the layer manager project than the selection syncing.

I'm not planning to look into properties editor syncing right now, but it's definitely something nice to have.

If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material?

Yes, I think so. Everything else would be just confusing.

Blender selection is more based on a hierarchy, e.g. active scene > active object > active material > active node. Would selecting in the outliner try to fit that kind of thing, so selecting a material in the outliner would make a particular object or even scene active so that the active material is shown? A material can be used by multiple objects though.

Current vanilla Blender works like this and I think it's pretty fine. It also selects the correct object when selecting a material.

Or would we introduce a new global selection state, where you have a list of selected/active datablocks (or other data types)? Other 3D 3D applications often work like this rather than with hierarchical selection. This would obviously be a big change.

Probably not a bad idea, but for later if at all.

If you select e.g. an image datablock or sequence strip, would we show this in the properties editor? It would make sense for consistency but that's now how Blender works currently.

The current properties editor has a weird scope. It contains scene settings and 3D View content settings, but not settings for other editors (movie clip editor, VSE, image editor, ...). It should either contain all settings of the scene and all editors, or it should only contain scene settings and each editor gets an own space to manage its settings (kinda like the properties region/n-panel, but meeeh). However, this is obviously a bigger design challenge too, nothing to discuss here and now ;) (would probably also need a more global selection context).

I'm going to look into the selection syncing in the coming days, had something similar in mind as @brecht wrote. Currently getting the base works using `BKE_scene_base_find` which uses slow listbase lookup. Could use a hash table, but not sure it's worth the extra memory. With the new layer system we could only iterate over the layers the object is in (object layers store a `Base *` array in current implementation). Anyway, just brainstorming about alternatives, I don't see a big urgency in changing. Will also look into making element selection consistent, this is actually more of an issue for the layer manager project than the selection syncing. I'm not planning to look into properties editor syncing right now, but it's definitely something nice to have. > * If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material? Yes, I think so. Everything else would be just confusing. > * Blender selection is more based on a hierarchy, e.g. active scene > active object > active material > active node. Would selecting in the outliner try to fit that kind of thing, so selecting a material in the outliner would make a particular object or even scene active so that the active material is shown? A material can be used by multiple objects though. Current vanilla Blender works like this and I think it's pretty fine. It also selects the correct object when selecting a material. > * Or would we introduce a new global selection state, where you have a list of selected/active datablocks (or other data types)? Other 3D 3D applications often work like this rather than with hierarchical selection. This would obviously be a big change. Probably not a bad idea, but for later if at all. > * If you select e.g. an image datablock or sequence strip, would we show this in the properties editor? It would make sense for consistency but that's now how Blender works currently. The current properties editor has a weird scope. It contains scene settings and 3D View content settings, but not settings for other editors (movie clip editor, VSE, image editor, ...). It should either contain all settings of the scene and **all** editors, or it should only contain scene settings and each editor gets an own space to manage its settings (kinda like the properties region/n-panel, but meeeh). However, this is obviously a bigger design challenge too, nothing to discuss here and now ;) (would probably also need a more global selection context).

Julian Eisel commented

2016-10-15 16:27:26 +02:00

Let me propose to take the following steps:

Get rid of the extra selection state, so that an element can either be selected, active (and selected), or unselected, just like anywhere in Blender.
Selecting an element that represents an object or belongs to one (e.g. material, texture, etc) selects the object and makes it the active one. Same for sequencer strips, masks etc.
Selecting an object changes all properties editors of the current layout to show the object context, same behavior for materials etc.
Make selection behavior consistent to rest of Blender, meaning normal LMB (or select-mouse?) replaces current selection, Shift+LMB adds to selection, etc.
And two things I'm not too sure about:
Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select.
When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc.

I'd really appreciate some quick feedback even if it's only a "+1" or "-1", since I'd like to start working on this now.

Let me propose to take the following steps: * Get rid of the extra selection state, so that an element can either be selected, active (and selected), or unselected, just like anywhere in Blender. * Selecting an element that represents an object or belongs to one (e.g. material, texture, etc) selects the object and makes it the active one. Same for sequencer strips, masks etc. * Selecting an object changes all properties editors of the current layout to show the object context, same behavior for materials etc. * Make selection behavior consistent to rest of Blender, meaning normal LMB (or select-mouse?) replaces current selection, Shift+LMB adds to selection, etc. And two things I'm not too sure about: * Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select. * When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc. I'd really appreciate some quick feedback even if it's only a "+1" or "-1", since I'd like to start working on this now.

Julian Eisel commented

2016-10-15 16:31:41 +02:00

To put my first two points differently: Don't use any extra selection state in outliner, the outliner should only display and allow changing selection states of the data it represents.

Brecht Van Lommel commented

2016-10-15 18:50:02 +02:00

I think it's definitely a good idea to try going in that direction.

In #37430#398720, @JulianEisel wrote:

Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select.

We could give some UI indication about this, maybe with preselection highlighting to indicate which ones are selectable. For some data we might consider introducing selection at some point, while for the User Preferences display selection doesn't make any sense to me now, I don't think we'd lose anything in that example.

When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc.

Not sure about this, there's so pros and cons. We could have a distinction between e.g. single click to select and double click to edit, though that also conflicts with double click to rename.

I think it's definitely a good idea to try going in that direction. > In #37430#398720, @JulianEisel wrote: > * Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select. We could give some UI indication about this, maybe with preselection highlighting to indicate which ones are selectable. For some data we might consider introducing selection at some point, while for the User Preferences display selection doesn't make any sense to me now, I don't think we'd lose anything in that example. > * When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc. Not sure about this, there's so pros and cons. We could have a distinction between e.g. single click to select and double click to edit, though that also conflicts with double click to rename.

Paweł Łyczkowski commented

2016-10-15 21:57:05 +02:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2016-10-15 21:57:05 +02:00

In #37430#398720, @JulianEisel wrote:
Let me propose to take the following steps:

Get rid of the extra selection state, so that an element can either be selected, active (and selected), or unselected, just like anywhere in Blender.

Selecting an element that represents an object or belongs to one (e.g. material, texture, etc) selects the object and makes it the active one. Same for sequencer strips, masks etc.

Selecting an object changes all properties editors of the current layout to show the object context, same behavior for materials etc.

Make selection behavior consistent to rest of Blender, meaning normal LMB (or select-mouse?) replaces current selection, Shift+LMB adds to selection, etc.

I would go with that, though I would only sync the selection (and highlight in Outliner) of items that have a physical presence in the 3d View. So, shift-LMB'ing on a material for instance would show that material in the Properties Editor, blink it once to confirm it was clicked , but wouldn't add it to the selection in the 3d View, and wouldn't keep it highlighted in the Outliner.

Unless there will be actions in the future that we'll be able to fire up in the Outliner that would affect multiple materials for instance (currently it seems it's not even possible to select more than one material). Then, I would go with: the non-physical datablock get's selected in Outliner, 3D View selection doesn't change.

And two things I'm not too sure about:

Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select.

I would go with the standard graying out things that can't be selected.

When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc.

I would go with no. I would guess the usual intention to select a datablock is to change it's properties, and the usual intention of going into Edit mode is to edit : )

Clumping things that happen in the interface like that create confusion IMO, and it's better to have 1 good way to do something (Tab/Button in the 3d View), than 1 good way + 5 weak ways.

If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material?

I guess making the interface less free and more 'standard' is a bad idea? Meaning - 1 Editor (except 3d View) per screen layout, global top bar, drag and droppable toolbars that can go in between areas, instead of the locked-in-place sidebars, a list of editors in a menu on the global bar from where they can be added, tabs in editors that users have often 2 instances of?

> In #37430#398720, @JulianEisel wrote: > Let me propose to take the following steps: > * Get rid of the extra selection state, so that an element can either be selected, active (and selected), or unselected, just like anywhere in Blender. > * Selecting an element that represents an object or belongs to one (e.g. material, texture, etc) selects the object and makes it the active one. Same for sequencer strips, masks etc. > * Selecting an object changes all properties editors of the current layout to show the object context, same behavior for materials etc. > * Make selection behavior consistent to rest of Blender, meaning normal LMB (or select-mouse?) replaces current selection, Shift+LMB adds to selection, etc. I would go with that, though I would only sync the selection (and highlight in Outliner) of items that have a physical presence in the 3d View. So, shift-LMB'ing on a material for instance would show that material in the Properties Editor, blink it once to confirm it was clicked , but wouldn't add it to the selection in the 3d View, and wouldn't keep it highlighted in the Outliner. Unless there will be actions in the future that we'll be able to fire up in the Outliner that would affect multiple materials for instance (currently it seems it's not even possible to select more than one material). Then, I would go with: the non-physical datablock get's selected in Outliner, 3D View selection doesn't change. > And two things I'm not too sure about: > * Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select. I would go with the standard graying out things that can't be selected. > * When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc. I would go with no. I would guess the usual intention to select a datablock is to change it's properties, and the usual intention of going into Edit mode is to edit : ) Clumping things that happen in the interface like that create confusion IMO, and it's better to have 1 good way to do something (Tab/Button in the 3d View), than 1 good way + 5 weak ways. >If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material? I guess making the interface less free and more 'standard' is a bad idea? Meaning - 1 Editor (except 3d View) per screen layout, global top bar, drag and droppable toolbars that can go in between areas, instead of the locked-in-place sidebars, a list of editors in a menu on the global bar from where they can be added, tabs in editors that users have often 2 instances of?

Julian Eisel commented

2016-10-16 17:53:14 +02:00

Committed first part of this to 2.8 branch, 9a9a663f40. The commit message lists the exact changes, I'll add some info on what's still needed to the task description.

In #37430#398924, @PawelLyczkowski-1 wrote:
I would go with that, though I would only sync the selection (and highlight in Outliner) of items that have a physical presence in the 3d View. So, shift-LMB'ing on a material for instance would show that material in the Properties Editor, blink it once to confirm it was clicked , but wouldn't add it to the selection in the 3d View, and wouldn't keep it highlighted in the Outliner.

The thing is the current Properties Editor depends on the object selection (except when using data-block fixing). Only object-settings/materials/etc of the active object are shown. Showing the materials of an unselected object would be pretty inconsistent behavior IMHO.

In #37430#398924, @PawelLyczkowski-1 wrote:

And two things I'm not too sure about:

Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select.

I would go with the standard graying out things that can't be selected.

There's a difference between editable and selectable. E.g. in the "User Preferences" display mode, the Outliner shows a bunch of settings. These settings may be editable, but the properties they represent aren't selectable data. My idea was to not allow selecting these (non-editable items are already grayed out).

In #37430#398886, @brecht wrote:

When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc.

Not sure about this, there's so pros and cons. We could have a distinction between e.g. single click to select and double click to edit, though that also conflicts with double click to rename.

In #37430#398924, @PawelLyczkowski-1 wrote:
I would go with no. I would guess the usual intention to select a datablock is to change it's properties, and the usual intention of going into Edit mode is to edit : )

Clumping things that happen in the interface like that create confusion IMO, and it's better to have 1 good way to do something (Tab/Button in the 3d View), than 1 good way + 5 weak ways.

That's true, but there is still some reasoning to consider. For example in the case of armature bones, which are only selectable while in Pose or Edit Mode. If we don't toggle into Pose Mode when selecting a bone from the Outliner, the Outliner and 3D View selection would differ again and I'd say we agreed that Outliner shouldn't have its own separate selection if possible.
Further, Outliner would allow you to quickly select the bone, without having to open a 3D view and changing into Pose Mode first.

Note that current Blender actually changes modes based on Outliner selection, so we'd basically remove a feature which is always tricky. Feedback from users who often work with the Outliner would be valuable.

In #37430#398924, @PawelLyczkowski-1 wrote:

If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material?

I guess making the interface less free and more 'standard' is a bad idea? Meaning - 1 Editor (except 3d View) per screen layout, global top bar, drag and droppable toolbars that can go in between areas, instead of the locked-in-place sidebars, a list of editors in a menu on the global bar from where they can be added, tabs in editors that users have often 2 instances of?

Blender's flexible windowing system is definitely one of its major strengths IMHO (and from many other opinions I've heard). Discussing this is outside of the scope of this task but I also don't think that this is a reasonable option. That said I do still think our windowing system can be further improved (and I have concrete plans for it, like the global topbar for example).

Committed first part of this to 2.8 branch, 9a9a663f40. The commit message lists the exact changes, I'll add some info on what's still needed to the task description. ---- > In #37430#398924, @PawelLyczkowski-1 wrote: > I would go with that, though I would only sync the selection (and highlight in Outliner) of items that have a physical presence in the 3d View. So, shift-LMB'ing on a material for instance would show that material in the Properties Editor, blink it once to confirm it was clicked , but wouldn't add it to the selection in the 3d View, and wouldn't keep it highlighted in the Outliner. The thing is the current Properties Editor depends on the object selection (except when using data-block fixing). Only object-settings/materials/etc of the active object are shown. Showing the materials of an unselected object would be pretty inconsistent behavior IMHO. > In #37430#398924, @PawelLyczkowski-1 wrote: >> And two things I'm not too sure about: >> * Don't allow selecting elements that can't be selected, e.g. elements in the User Preference display mode. Could however confuse the user on why he can't select. > > I would go with the standard graying out things that can't be selected. There's a difference between editable and selectable. E.g. in the "User Preferences" display mode, the Outliner shows a bunch of settings. These settings may be editable, but the properties they represent aren't selectable data. My idea was to not allow selecting these (non-editable items are already grayed out). > In #37430#398886, @brecht wrote: >> * When selecting a mesh element, should we toggle into edit mode? Same question for pose bones, GPencil strokes, etc. > > Not sure about this, there's so pros and cons. We could have a distinction between e.g. single click to select and double click to edit, though that also conflicts with double click to rename. > In #37430#398924, @PawelLyczkowski-1 wrote: > I would go with no. I would guess the usual intention to select a datablock is to change it's properties, and the usual intention of going into Edit mode is to edit : ) > > Clumping things that happen in the interface like that create confusion IMO, and it's better to have 1 good way to do something (Tab/Button in the 3d View), than 1 good way + 5 weak ways. That's true, but there is still some reasoning to consider. For example in the case of armature bones, which are only selectable while in Pose or Edit Mode. If we don't toggle into Pose Mode when selecting a bone from the Outliner, the Outliner and 3D View selection would differ again and I'd say we agreed that Outliner shouldn't have its own separate selection if possible. Further, Outliner would allow you to quickly select the bone, without having to open a 3D view and changing into Pose Mode first. Note that current Blender actually changes modes based on Outliner selection, so we'd basically remove a feature which is always tricky. Feedback from users who often work with the Outliner would be valuable. > In #37430#398924, @PawelLyczkowski-1 wrote: >>If you have two properties editors open and you select a material in the outliner, would both editors be modified to show the material? > > I guess making the interface less free and more 'standard' is a bad idea? Meaning - 1 Editor (except 3d View) per screen layout, global top bar, drag and droppable toolbars that can go in between areas, instead of the locked-in-place sidebars, a list of editors in a menu on the global bar from where they can be added, tabs in editors that users have often 2 instances of? Blender's flexible windowing system is definitely one of its major strengths IMHO (and from many other opinions I've heard). Discussing this is outside of the scope of this task but I also don't think that this is a reasonable option. That said I do still think our windowing system can be further improved (and I have concrete plans for it, like the global topbar for example).

Paweł Łyczkowski commented

2016-10-16 19:15:04 +02:00

Blender's flexible windowing system is definitely one of its major strengths IMHO (and from many other opinions I've heard). Discussing this is outside of the scope of this task but I also don't think that this is a reasonable option. That said I do still think our windowing system can be further improved (and I have concrete plans for it, like the global topbar for example).

Yeah, it seems there are many cases where users have 2 editors of the same type open, so a single editor system is not feasible.

> Blender's flexible windowing system is definitely one of its major strengths IMHO (and from many other opinions I've heard). Discussing this is outside of the scope of this task but I also don't think that this is a reasonable option. That said I do still think our windowing system can be further improved (and I have concrete plans for it, like the global topbar for example). Yeah, it seems there are many cases where users have 2 editors of the same type open, so a single editor system is not feasible.

Brecht Van Lommel commented

2016-10-16 19:33:38 +02:00

If there are multiple properties editors open, we can change just one editor when changing selection in the outliner.

We could have some settings to let the user specify which properties editor is the selection sensitive one. In most cases I imagine it being the first created properties editor in the screen is fine, and users would rarely need to change this.

There could be some visual indication for this, around the pin icon and data path.

If there are multiple properties editors open, we can change just one editor when changing selection in the outliner. We could have some settings to let the user specify which properties editor is the selection sensitive one. In most cases I imagine it being the first created properties editor in the screen is fine, and users would rarely need to change this. There could be some visual indication for this, around the pin icon and data path.

Paweł Łyczkowski commented

2016-10-16 21:05:49 +02:00

In #37430#399087, @brecht wrote:
If there are multiple properties editors open, we can change just one editor when changing selection in the outliner.

We could have some settings to let the user specify which properties editor is the selection sensitive one. In most cases I imagine it being the first created properties editor in the screen is fine, and users would rarely need to change this.

There could be some visual indication for this, around the pin icon and data path.

I'm not sure it's even a problem for the properties editor. If there are 2 properties editors open, they are usually (and logically) in different modes/tabs, and I see that the tabs do not switch to, for instance, the material tab when selecting a material.

Could be more of a problem if you could browse images for instance in the Outliner - but I see that currently you can't.

> In #37430#399087, @brecht wrote: > If there are multiple properties editors open, we can change just one editor when changing selection in the outliner. > > We could have some settings to let the user specify which properties editor is the selection sensitive one. In most cases I imagine it being the first created properties editor in the screen is fine, and users would rarely need to change this. > > There could be some visual indication for this, around the pin icon and data path. I'm not sure it's even a problem for the properties editor. If there are 2 properties editors open, they are usually (and logically) in different modes/tabs, and I see that the tabs do not switch to, for instance, the material tab when selecting a material. Could be more of a problem if you could browse images for instance in the Outliner - but I see that currently you can't.

Julian Eisel commented

2020-06-26 18:07:48 +02:00

Changed status from 'Confirmed' to: 'Archived'

Julian Eisel closed this issue

2020-06-26 18:07:48 +02:00

Julian Eisel self-assigned this 2020-06-26 18:07:48 +02:00

Julian Eisel commented

2020-06-26 18:07:48 +02:00

This task is quite old and updated I think. Will close it in favor of #77408.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Review Preselection in Outliner #37430