The problem is, that the “multiple” property (which let’s us know, if the shift key has been pressed while selecting) is part of the SelectionEvent. As far as I see it, there is no SelectionEvent, if no object has been clicked. Consequently, there is no “multiple” property and I am unable to know if the shift key has been pressed or not.
And that’s also the situation where I am currently standing at with the viewer API in our own web app.
I’m trying to reproduce what the user would expect:
only clicking the background → unselect all
shift + clicking the background → current selection doesn’t change
It’s easier to miss elements than one would expect, and then the entire selection is lost. As seen in the video. And it’s quite frustrating. Especially, since “area select” (selecting multiple elements by drawing a rectangle) doesn’t exist (sadly ) and selecting hundreds of elements one by one is my only chance.
So my question to @alex would have been if that’s changed in the Viewer API 2.0? But as far as I could already see, it doesn’t seem to. I guess, it’s been more about other things.
And talking about “shift + click” I’d actually prefer (or would have assumed) that “ctrl + click” would have been the way to select multiple elements. At least, I am more used to that version in 3D modelling or anywhere else.
And just to give it a tiny tiny bit more weight. I totaly agree with @gokermu … we need to be able to look from underneath. Depending on the geometry, even to have a look at some elements above the ground. Or yes … to comment some ceilings. or bearers.
So, I am also happy apout the control modes.
API 2.0 works the same way when it comes to clicking on objects. Clicking on nothing will provide you with a null SelectionEvent. Your point about easily being able to miss objects, and thus messing up the entire group selection is very valid and I understand completely.
The good news is that even if API 2.0 doesn’t come with a new behavior regarding this, we can change it’s default behavior by extending the SelectionExtension which handles these things.
Here’s a link to a sandbox that does just what you described : silly-estrela-g3lfs6 - CodeSandbox
It’s not ideal, but it’s short and simple and can easily be used as an alternative until the SelectionExtension can offer this as a built in feature/option.
Regarding the topic “ctrl” vs “shift” this can be something we will take into consideration and off the top of my head, will probably offer it as an option you can change in the default SelectionExtension
As for box selection, if I can find the time, I will make an extension that allows it. Ideally, this extension would need to wait until API 2.0 exposes the acceleration structures and centralizes interesections which we planned on doing in a future iteration. But, I think it can be done with the current version as well.
Finally, I want to thank you for bringing this up and encourage you and everybody who might be reading this, to give us all the feedback you can on API 2.0, so we can make the best library we can out of the speckle viewer.
The code you linked is super helpful, also for understanding the new viewer API in general and their option for extensions. As I understand, that’s some new feature for API 2.0 … I still have to switch to 2.0, but I had a look and it seems to get quite powerful. So thanks a lot for that and the efforts behind it.
As already mentioned, an option for ctrl/shift is super nice , and also I am (honestly) very excited to hear that box selection might come true.
Sometimes, those things might seem to be “some interface details”, but I think it’s not. It’s getting more and more obvious, that those things might be the crucial point wether our colleagues will adopt our tools or not (besides the functionality of the tool itself). Adoption is the final boss enemy.
It’s WIP @samberger, but we are happy that you are happy.
A beneficial side-effect of modularising many aspects of Speckle is that the potential for Community contributions is greatly enhanced.
Come up with a viewer extension, which is a great code contribution to be made, and there is no need to grok the entirety of the viewer and front end before doing so.
It’s an example demonstrating the concept of box selection with API 2.0, not necessarily the most efficient and most certainly not very polished, but it gets the job done for most use cases.
No worries, I’ve already seen your box selection example at Speckle Con and have been super excited about it (and still am). I think, it’s a super important feature. The sandbox is also very helpful.
) and selecting hundreds of elements one by one is my only chance.
or bearers.
So thanks a lot for that and the efforts behind it.
I think, it’s a super important feature. The sandbox is also very helpful.