Add a way to select `Thing`s from a `thing_slot`

[rwb27]

The new thing_slot introduced in #194 should be ideal for plugins: by declaring a mapping slot with the right type, a Thing can access all instances of PluginThing on the server.

It's common to want to choose a plugin - e.g. set the current method used for background detection or scan planning in an OFM. Currently, this can be done with a string - but it would be lovely to have the available Thing names appear as enum options, so that UI code can automatically generate a drop-down selector.

This is not possible at the moment, because the TD is generated from static types, and said static types don't know what Things are available in the server.

I propose we allow the model (but not the value_type) of properties to depend on the host Thing. Doing so means that we could declare the property as a string, but include it in the TD as an enum. We could do run-time validation of the string, but by restricting it to the correct values in the schema, we make it much easier to generate a nice UI.

This is unlikely to make it for the next release, but maybe the next one...

[julianstirling]

Need to consider also how we:

• clearly define the default
• ensure the selected is saved with settings
• fallback to the default if the saved choice isn't selected.

If an enum is used it must be saved to disk as a key not the integer or the selection will change if the matching things are reordered

[julianstirling]

🚨 Half-baked Idea Alert 🚨

What if instead of being a generic Mapping it was a lt.Thing Group? So then we can easily add functionality to it?

class CameraThing(lt.Thing):

    background_detectors: lt.ThingGroup[BackgroundThings] = lt.thing_slot()

As it is now a defined object it should be easy enough to add methods/properties so we can do self.background_detectors.select(name) or

@property #Normal property for internal use
def active_detector(self):
    self.background_detectors.active_thing

What I am not sure is how this saves or can be switched over UI. It would be possible to say that any lost that has a ThingGroup is always a Setting (or has an associated setting)? I can also think there may be times where selecting which thing is active doesn't actually make sense. So it may be we need two mapping type classes:

1. If it is just a generic collection of things for use
2. If it is a specific one active from a group of Things

class CameraThing(lt.Thing):

    background_detectors: lt.ThingPool[BackgroundThings] = lt.thing_slot()

    camera_extensions: lt.ThingCollecton[CameraPluginThings] = lt.thing_slot)

In which case background detectors are selectable, one is always active (there needs to be some way to create a setting for selection). The camera extensions are just a group of plugins, no specific one is "active".

[rwb27]

That approach is quite tempting, though it does make me slightly regret making thing slots field typed - we could equally well do:

class CameraThing(lt.Thing):
    background_detectors = lt.selectable_thing_slot(BackgroundThings, default="whatever")

This would type hint fine, and I think it's shorter and clearer - but it looks less like the syntax for lt.property which I think we all quite like now.

I quite like the simplicity of having a single attribute that takes care of everything, though it does present a slight difficulty in that we'd want to expose a property (more likely a setting) that corresponds to the name of the selected thing. That probably shouldn't be advertised as the name of the thing slot, and at the moment we don't support properties with dots in the name. Probably that's something to figure out, but I'd prefer to leave that thinking for another day...

For now, I can see my way to implementing a slightly less elegant structure that would look like:

class CameraThing(lt.Thing):
    _all_background_detectors: Mapping[str, BackgroundThing] = lt.thing_slot()

    background_detector: BackgroundThing = lt.selectable_thing_slot()

    background_detector_name = lt.thing_slot_selector(default="default_thing_name")

I think it would be easy enough to eliminate the first attribute if we wanted to, it could be created automagically by background_detector when the class is finalised. No type hint would be needed for background_detector_name I think, because it will have a sensible static return type.

I suppose, thinking about it, all we really need is an interface to set the name of the Thing we want (because getting the name would be background_detector.name as that's a property of Thing already). We could use the setter of the property to accept a string. That would have the significant drawback of being a nightmare to type, because you'd be assigning strings to a property that returns a Thing subclass. I don't like that as an option!

I think the main thing lacking from what I've just described is a way to enumerate the possible Things if the first attribute is hidden. I suspect that's not worth worrying about for now.

[rwb27]

The more I write about the implementation the more I like your suggestion for a single descriptor that does everything. I still think I could implement what I've suggested rather faster and with less new testing required - but perhaps we'd do well to think of it as a stepping stone to something that looks more like what you've described.

[rwb27]

I think the trickiest aspect of this (and it would need to happen whatever implementation we use) is that we will need to allow the model of a setting to depend on the Thing instance rather than just the class. I will make a start on that, probably I should make a PR that's just that feature, and another one that uses it to implement thing selection.

I have flip-flopped on whether it's better to bundle all the functionality into one Descriptor, or spread it out across several - I think the principle of making the ThingClient and the Thing have the same signature is a good one, and it is quite hard to do if we bundle everything into a single Descriptor - but as you know I also really hate boilerplate...

#258 will help here - if we could say self.thing_slots["whatever"] it provides a place to put the less-used features without cluttering the class namespace too much.