PulseView/Concepts

These are ideas that need discussion and implementation.

Issues to discuss at the PV concept meetup

Idea: Select mode vs. drag mode for the view

Currently, the user has no means of selecting anything. We definitely need this ability, though, for example to let the user specify a range that the decoders should decode.

My idea (abraxa) is to let the view operate in two modes: select mode and drag mode. The default would be select mode where a drag across the view selects a range.

The user can switch to drag mode by pressing CTRL while dragging. Alternatively, we could also think about using the right mouse button for this, though it might interfere with context menus that we'll eventually see being used on the view.

Idea: Mobile UI vs. Desktop UI

Currently, PV tries to satisfy both worlds at the same time. I don't think this works well at all. My suggestion (abraxa) is to show a different style of UI depending on the device.

Mobile UI:

No menu
All menu items moved to burger menu
Dragging in the view moves the traces
Additional toolbar button visible that lets the user toggle between "drag" and "select" mode for the view

Desktop UI:

Menu always visible
No burger menu button
Dragging in the view selects a range, dragging with CTRL pressed moves the traces

Idea: Group handle bar enhancement

There's currently no way to shrink/enlarge a group of traces. I (abraxa) suggest we make handle bars behave differently, depending on where the user clicks it:

Upper 1/3rd:  Resize trace group vertically (bottom of trace group is unaffected)
Middle 1/3rd: Move trace group vertically (size is unaffected)
Lower 1/3rd:  Resize trace group vertically (top of trace group is unaffected)

Idea: Pseudo scope mode

A valid use case for PV is to use it like a scope. This however currently doesn't really work very well as PV treats all data as streaming data. In order to make PV behave like a scope, I (abraxa) suggest we add a pseudo scope mode that the user can enable.

In this mode, PV requires a trigger to be set. The ruler no longer shows a continuous time but instead a "-xx ms" to "+xx ms" time relative to t=0 where the trigger occurred.

The trigger would by default be positioned at 50% of the view's width. Data would be handled as in stream mode, i.e. appended to the existing data. However, the view doesn't scroll.

When a new trigger packet arrives, the view is showing the new trigger at the desired t=0 location (e.g. 50%), along with the data surrounding it.

Idea: Brower-like tabbed UI

As there's currently ony one hardcoded view, there's no way to compare two views or do anything else that requires more than just one view.

In order to allow for more complicated usage scenarios, we need a mechanism that permits showing several windows at once (e.g. measurement + tabular packet view, two measurements side-by-side). We could do this using MDI but a tabbed interface seems more appropriate. The reason for this is that everyone is familiar with browser-like tabbed UI and because it suits our purpose well.

We could (and should) then also include a session management that saves/restores the user's current "workspace".

Idea: Collapsible logic groups

With vertical space at a premium, having logic channel groups use up so much vertical space is kind of a luxury. We should have a way for users to show logic trace groups in a "compact" way, i.e. toggle between normal height and 1/3 the normal height.

By collapsing the traces and making them visible all at once, we can also provide built-in alternative displays. GTKWave for example lets users bundle up signals and show them in hex/dec/bin or ASCII. With traces being compacted, we could offer the same option, essentially removing the need for the "parallel" decoder.

Idea: Drag-n-drop measurements

In order to facilitate quick measurements, we could provide a window that contains measurement operators. Dragging one of those onto a signal (or signal group handle?) could add this kind of measurement to that signal.