Not sure if this makes sense to add. The most useful thing to me, if you don’t know the shortcut, seems to be to select an element, and then use the operator to select linked.

If we added this, it should also be added to the UV Editor, but overall I’m not entirely convinced of the usefulness of this. But don’t have a strong opinion either way.

@William Reynish (billreynish) : Hi William, a relating proposal was brought up over at Devtalk. I post the link here as it's worth to reread it regarding this patch and for further thoughts about why it is useful and how it could be embedded in blenders workflows.

https://devtalk.blender.org/t/in-the-sub-object-levels-there-should-be-an-element-level/9396

Well, perhaps it's okay to add this. The delimiting controls do make the tool rather useful in certain circumstances.

The next obvious thing to point out, is that it's of course a little inconsistent with the UV Editor, where Island selection mode appears as a selection mode rather than as a tool. However, I also understand why you didn't go this way in the 3d view, since 1, that would open a can of worms in terms of how that behaves and works, and 2, there would then not be an obvious place to put the selection delimit controls.

Of course it would also need an icon, but that could be committed separately. And your list of limitations would also have to be addressed.

I'd like to get some more perspectives from other developers also.

Why not make it like other dcc apps do, double click on a face selects the island. Pretty standard.

Thanks for the input!

In D6518#153622, @William Reynish (billreynish) wrote:

Not sure if this makes sense to add. The most useful thing to me, if you don’t know the shortcut, seems to be to select an element, and then use the operator to select linked.

I'm aware of that operator but it gets rather tedious if you use it repeatedly. Select_linked_pick helps already alot as it removes one step however it is also rather awkward to use, especially when you want to alter between ADD/SUB behavior.

I think it becomes apparent why this is usful in specific use-cases. So i can explain a use-case that i'm often faced with briefly:

When doing product visualization of hardsurface objects the models often come from cad software. So in order to visualize a model in blender it has to be converted to a mesh first. This means the topology isn't optimal and surfaces that were just one element in cad-format are now subdivided in different faces. As you almost only want to select those cad elements it makes sense to first mark all hard edges as sharp and then use the select_linked operator.

If we added this, it should also be added to the UV Editor

Makes sense!

In D6518#153634, @Debuk (Debuk) wrote:

@William Reynish (billreynish) : Hi William, a relating proposal was brought up over at Devtalk. I post the link here as it's worth to reread it regarding this patch and for further thoughts about why it is useful and how it could be embedded in blenders workflows.

https://devtalk.blender.org/t/in-the-sub-object-levels-there-should-be-an-element-level/9396

Thanks for the link, i wasn't aware of that thread. Nice to see that others are looking for such a functionality as well.

In D6518#153653, @William Reynish (billreynish) wrote:

Well, perhaps it's okay to add this. The delimiting controls do make the tool rather useful in certain circumstances.

The next obvious thing to point out, is that it's of course a little inconsistent with the UV Editor, where Island selection mode appears as a selection mode rather than as a tool.

From UI perspective it indeed makes sense to have it as a selection mode but i think you would then lose the ability to only select linked vertices/edges.

Indeed - I only mention it because it’s a somewhat obvious comment, but I do see the advantage of it being a tool instead. For the UV Editor, maybe it’s not necessary since we have Island select mode.

@David Friedli (hlorus) @William Reynish (billreynish) : Hi David, yes I guess quite some people hope for such an improvement. I think it's great. The control is faster and much more direct that way. I also thought if it's better to have a fourth mode or treat it as a tool as you did. But both method have their pros and cons

Would it be much work to get this direct selection behaviour with this oneclick back to an operator version, so that no explicit selection of an vertex, edge or face prior to that is neccessary? That way it would be possible to embed it better into the typical selection control schemes with mouseclicks and/or modifier keys as @Regnas (Regnas) hinted. That could improve the control method in all cases where its not needed that often that a change to the distinct tool makes sense. That would complete the control scheme in terms of island selections in my view.

FIY: As I tested it this morning. I am currently getting an IndexBoundsException when I am leaving editmode and the tool is still the activated selection method.

@Debuk (Debuk)
I'm not sure if i understand your question correctly. The oneclick behavior comes from the mesh.select_linked_pick operator which already has a shortcut binding (L). When invoked the operator looks for the element under the mouse cursor and then does the same as the select_linked operator.

This patch just exposes the _pick operator also as a tool and defines following keybindings when the tool is active:
-LMB -> to SET a new linked region
-Shift+LMB -> to ADD a linked region to already existing selection
-Ctrl+LMB -> to SUBTRACT a linked region from already existing selection

FIY: As I tested it this morning. I am currently getting an IndexBoundsException when I am leaving editmode and the tool is still the activated selection method.

Thanks for the testing! I will look into that.

In D6518#153655, @Regnas (Regnas) wrote:

Why not make it like other dcc apps do, double click on a face selects the island. Pretty standard.

The select_linked operator is quite versatile and can also do selections limited by e.g. seam, sharp or material. How would you cover all those options?

It could probably be a handy addition but when it doesn't cover the whole functionality it's not a real alternative to the suggested solution and can probably not be part of this patch. So that discussion is best kept in the devtalk thread.

@David Friedli (hlorus) Thanks much for the info. I wasn't aware of the availability of the _pick variant and have simply assumed you covered the changes within this patch. I am testing the intregration of the _pick variant in my keymap right now. And yes it's exactly what I was asking your for, sorry for that, I wasn't aware of that, cause it's nowhere utilized in the Industry Compatible Keymap, which I am using for Blender.

I am pretty sure Regnas refers to how it is in Cinema4D. That doesn't cover all these options blender offers, but for most work its enough to have the "normal" variant. Maxon integrated the island selection into what I'd describe as the mouse core control scheme ( Mouse Buttons and Keyboard Modifier keys). Dbl clicking faces selects an island and it can be extended or substracted with shift and ctrl as modifiers. It's indeed pretty nice and fast that way, but I would NOT suggest to see that as an alternative to your idea/patch. Both input methods, your tool and such kind of shortcuts would rather complement each other well. So what could be an idea generally is, to adapt the operator for the shortcuts to use the current setup of the tool variant.

That way the logic behind it would be quite similar to how the selection fallback for the tools currently works.

In D6518#153946, @Debuk (Debuk) wrote:

I am pretty sure Regnas refers to how it is in Cinema4D. That doesn't cover all these options blender offers, but for most work its enough to have the "normal" variant. Maxon integrated the island selection into what I'd describe as the mouse core control scheme ( Mouse Buttons and Keyboard Modifier keys). Dbl clicking faces selects an island and it can be extended or substracted with shift and ctrl as modifiers. It's indeed pretty nice and fast that way, but I would NOT suggest to see that as an alternative to your idea/patch. Both input methods, your tool and such kind of shortcuts would rather complement each other well.

That should be possible with some simple keymap changes. If you're suggesting that this is in the default or industry compat keymap, that's probably mostly a design decision.. @William Reynish (billrey)

@David Friedli (hlorus) Yes I know that, thanks anyway. I wrote that rather as an info for you. I already have set it up testwise, and probably will suggest it if I will find an equally nice remapping for the conflicting loopselections that aligns with the idea of this keymap. Haven't yet found the time to think about that.

But that control would solve an initial concern fo yours for the pick variant to feel awkard if a mouse aim and keyboard click is needed to trigger.

This patch has an approved status however it was not committed yet. So I'm assuming the other reviewers are blocking. Updating the reviewers list to reflect this. This way the patch status still show as Need Review.