MetaEventTabView¶

class MetaEventTabView()

Shared base for the Views of the two event-oriented analysis tabs.

RawDataView and EventAnalysisView both drive a tab that works from a reader and a time-series channel rather than from a database of results: the user picks a reader, a filter and a channel, and the tab finds or fits events in the raw signal. The two carried five methods verbatim between them; this base holds that shared half so there is one copy to fix.

What a subclass inherits:

Two of ``MetaView``’s abstract hooks, made concrete. notify_plugin_state_changed is a deliberate no-op for both tabs - neither shows a database column list, so a plugin-state change elsewhere in the app is not their business - and _reset_actions clears the figure identically in each. MetaView still declares both abstract; satisfying them here is what keeps both subclasses instantiable without a per-tab copy.
_channels_from, which reads the channel selection out of a parameter dict and reports a missing one as ValueError, which every caller already guards.
Commit-time helpers. _extract_commit_event_parameters and validate_single_channel read the controls panel’s channel selection and reject anything that is not exactly one channel.
The event-index range helpers. _parse_event_indices, _expand_event_indices, _shift_ranges, _merge_ranges and _format_ranges turn the event-index field’s text into ranges and back. Only these two tabs call them, which is why they are here rather than on MetaView; they are pure apart from one logger call.

What a subclass owes it:

Its own logger = logging.getLogger(__name__), so records made by the methods it defines itself stay attributed to its own module.
``MetaView``’s remaining abstract methods - _init, handle_parameter_change and update_available_plugins - which this base does not implement.

ivar logger:: the module logger the shared methods below log under

Public Methods¶

Abstract Methods¶

These methods must be implemented by subclasses.

(none)

Concrete Methods¶

MetaEventTabView.confirm_unfiltered_run(operation: str) → bool¶

Ask the user to confirm launching an analysis with no filter selected.

Running an event finder or fitter on unfiltered data is a legitimate choice, but on a noisy trace it can be a degenerate one: the threshold is crossed constantly and effectively every sample registers as an event, which grinds for a very long time and is easy to mistake for a hang. Cancelling does work - find_events reads the abort flag at every chunk boundary and breaks out of the range immediately - but with that many events a single chunk takes long enough that the cancel can look as though it has not registered.

Shared by the two tabs that launch this kind of work rather than copied into both. It is stateless and adds no contract, which is what makes it safe on the common base: it carries no instance state and adds no abstract hook, so a subclass that never calls it pays nothing.

Parameters:: operation (str) – what is about to run, named for the prompt, e.g. “Event finding”
Returns:: True to proceed, False if the user declined
Return type:: bool

MetaEventTabView.notify_plugin_state_changed(metaclass: str, plugin_key: str, reason: str) → None¶

This tab does not currently react to any plugin_state_changed notifications.

Parameters:

metaclass (str) – The metaclass of the plugin instance whose state changed.
plugin_key (str) – The unique key identifying the plugin instance that changed.
reason (str) – A short string identifying what kind of change occurred.

Returns:

None

Return type:

None

MetaEventTabView.validate_single_channel(channels: Sequence[int]) → None¶

Ensure only one channel is selected.

Parameters:: channels (Sequence[int]) – List of selected channel indices.
Raises:: ValueError – If more than one channel is selected.

Private Methods¶

Abstract Methods¶

These methods must be implemented by subclasses.

(none)