UI for selecting reader plugin

[tlambert03]

Proposal:

• User drags file into napari
• UI pops up showing a group of radioboxes with all readers that can read that file
  • for npe2, we can use iter_compatible_readers
  • for npe1, we could also mock this functionality by seeing which readers actually return a function
• there's a checkbox that says "remember this settings", and tells them where to change in (in the preferences somewhere).

cc @DragaDoncila @nclack

[tlambert03]

one difficult challenge is how do we store this info? naively, it could be a map of extension to plugin... but that glosses over a lot of the power in the get_reader spec, that technically allows a plugin to take a peek at the file (header? name? etc...) before opting in/out. So so if the user drags file A and chooses reader X in our dialog, what feature of file A do we use? i suspect in many cases we'll be ruining the power of the reader priority list. On the other hand, that reader priority list is probably something that many people will be confused by. so, who knows

[DragaDoncila]

but that glosses over a lot of the power in the get_reader spec, that technically allows a plugin to take a peek at the file (header? name? etc...) before opting in/out. So so if the user drags file A and chooses reader X in our dialog, what feature of file A do we use?

Yeah I tend to agree that associating by extension isn't the best option. I feel like we should actually check that a reader function is returned for npe2 plugins as well. Otherwise we risk iterating compatible readers by extension - user picks one - that one fails, and now it's associated so you have to go into preferences to change it.

Could we somehow associate by extension and the napari_get_reader validating function? And when a new file is dragged in, check that both conditions are met before trying to read with that reader - and if both don't match we pop up the dialog again?

[DragaDoncila]

^Of course we'd be trading off responsiveness there - and also the whole "not running code until we need to" concept

[tlambert03]

I feel like we should actually check that a reader function is returned for npe2 plugins as well

sure, sounds good. just go one step beyond iter_compatible_readers ...

And when a new file is dragged in, check that both conditions are met before trying to read with that reader - and if both don't match we pop up the dialog again?

that sounds like a great idea!

[tlambert03]

^Of course we'd be trading off responsiveness there -

I think the responsiveness will be fine.

and also the whole "not running code until we need to" concept

that is true for npe2 readers, and something that would be nice to avoid. Maybe just use the iter_compatible_readers for now, and then after the user has selected one, if it doesn't return a function, we go back and offer again?

[DragaDoncila]

Maybe just use the iter_compatible_readers for now, and then after the user has selected one, if it doesn't return a function, we go back and offer again?

Yep, I like that.

[nclack]

see napari/napari#3799

[nclack]

closing now that napari/napari#3799 is merged