Difference between revisions of "PulseView/Concepts"
(Initial draft) |
(More ideas) |
||
Line 3: | Line 3: | ||
== Issues to discuss at the PV concept meetup == | == Issues to discuss at the PV concept meetup == | ||
=== Idea: Select mode vs. drag mode for the view === | === Idea: Select mode vs. drag mode for the view === | ||
Line 59: | Line 50: | ||
=== Idea: Brower-like tabbed UI === | === 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. |
Latest revision as of 21:25, 1 February 2016
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.