Demodulators aren't notified of any events

[bitglue]

For the WSPR demodulator (#82) I have use cases for three kinds of events:

• The receiver was deactivated due to being out of range, so it can stop invoking wsprd.
• The receiver frequency has changed, so it can invalidate the current recording, thus avoiding reporting spots on one frequency which happened on another.
• The receiver is being destroyed, so temporary files can be deleted.

There are ways I could work around these limitations, but none are especially elegant.

• I could infer the demodulator has been disconnected by inspecting how many samples it's recorded, though this is only indirectly what I need to know, and relies on an implementation detail.
• I can poll the demodulator context for frequency changes, but polling doesn't seem appropriate in this case.
• I can use __del__, but explicit .close() methods are generally good practice.

[kpreid]

• The receiver frequency has changed, so it can invalidate the current recording, thus avoiding reporting spots on one frequency which happened on another.

You can almost get this notification by implementing ITunableDemodulator. The catch is that that only promises to notify you about the relative frequency, which can remain unchanged if in freq_linked_to_device mode. In practice, it currently delivers notifications on any change, but I wouldn't propose relying on that.

I agree that all three of these are useful. I'll see about implementing them.

[kpreid]

710e578fea36b75e04613f1da367096689a8c657 replaces ContextForDemodulator.get_absolute_frequency with ContextForDemodulator.get_absolute_frequency_cell, so you can subscribe for frequency changes.

I'm figuring to do the same thing (provide a cell from the context) for out-of-range, and maybe close/delete. The rationale is that this avoids obligating demodulators that don't need the information to implement several stub methods.

Does this sound like a good plan?

[bitglue]

What's a cell? Looks like a value that can either be .get() or somehow subscribed? Sounds good, though tangentially stuff in values.py could use some docstings.

[kpreid]

What's a cell? Looks like a value that can either be .get() or somehow subscribed?

That's correct. Each @exported_value implicitly generates a cell (per instance, of course). Most of the code that works with cells explicitly is on the client side for UI generation and data binding.

…stuff in values.py could use some docstings.

Well, yes. It's a bit of a mess other ways, too.