[jfengel]

I don't know when I would use that. If that's something a user would do often I probably want some other design component.

In part it's because I don't like check boxes. They don't have great feedback about what's going to happen. If I designed a UI where someone is likely to check a lot of boxes, I would feel I had done something very wrong.

Sometimes it's unavoidable and so the framework might as well allow it. And as a user, designers often do things I wouldn't have. But I can say I don't miss having that feature.

[mewpmewp2]

Maybe when you have e.g. a list of items/pictures/datasets you want to select to perform some action with, e.g. download, export, or perform some bulk job on?

[jfengel]

With pictures I'd rather use select features: draw a box, shift click, etc.

File choosers usually do something like that, rather than a separate check box component. You select the icon rather than a check box near the icon, so it's slightly clearer what it is you want operated on.

Ideally you'd find other ways to narrow the list. A long list of items is a UX disaster waiting to happen. The more you can categorize your data beforehand, the better off you are. If you can make it all-or-nothing, you're less likely to mis-click.

[paradox460]

I really wish more file choosers would adopt both. Checkboxes are good for making complex, discrete selections that persist through accidental clicks. I can't tell you the number of times I've made a discrete selection of several items, only to lose it because the click misregisters on background instead of the icon