Arbitrary triggers are a frustrating thing to express in a generic way given that (a) you want some things to be first-class GUI, e.g. threshold levels and (b) every scope probably has different limitations on exactly how flexible you can be. I would suggest implementing something 'good enough for now' before trying to build something which might be 'universal enough'. Two example non-trivial things I use a lot with my pico3k, in case they inspire anyone:

• AND/OR combinations of multiple channels (e.g. 'edge ch1' AND ('pulse width ch2' OR 'edge ch3'))
• both upper/lower thresholds (where relevant) and hysteresis offsets for the thresholds - ideally in the GUI :)

"Good enough for now" was the initial goal (edge triggers only). This is, however, rapidly becoming insufficient.

Proposal: Oscilloscope::SetTrigger() takes a pointer to a polymorphic Trigger object (presumably owned by the OscilloscopeWindow).

Each derived class, such as EdgeTrigger or I2CProtocolTrigger, will have configuration fields specific to its own use, and may derive input from one or more channels of the instrument. Use a dynamic creation method similar to what we have in the Oscilloscope and ProtocolDecoder classes.

Add a method to Oscilloscope to return a vector of supported trigger types for populating a dropdown in the (currently extremely spartan) trigger properties dialog. We can then use RTTI to check the currently enabled trigger and enable special UI elements, or use something generic like we currently use for ProtocolDecoder properties if there's no special-case GUI logic.

The groundwork for this will be (relatively) easy to do, and it's extensible with additional trigger types very easily.

So you can handle combinations of triggers by just making a wrapper Trigger class? I think "hardcoding" knowledge of the triggers via RTTI in the GUI is inevitable + makes sense.

And add method(s) to the Oscilloscope class where it gives you the limitations for a specific trigger, if any? e.g., whether hysteresis offsets are supported, or whether it's possible to add another trigger to a boolean combination.

I think I'm going to PoC this by implementing a few basic trigger types in the proposed new API, then see how it works.

This also ties into #100, and is blocking things like I2C protocol trigger support as well.