|Re: [tracecompass-dev] Ideas about pin and new view features|
| CFV-A | CFV-B |
| RV-A* | RV-B |
| CPUU-A* |
| Trace A*| Trace B |
OK, I'm making this more complicated than my original use case so that we can foresee potential issues:
Not sure I got all of this but let's say you have the notion of container (pick your poison here) how does this could be achieved (illustrate if you can).
If we have an initial version with no time-synchronization of pinned views, I don't think it needs to be delayed while we figure out how to control and apply the trace synchronization.
I do agree here. But you understand that this (no time-synchronization of pinned views) imply that in the short term a user will not be able to compare graphical views between traces (same as of now).
Initially the purpose of an experiment was to merge multiple traces into one chronologically, at a stage where there could only be one trace/experiment opened at a time. It's when support for multiple opened traces was added that time-synchronization of traces was implemented, to provide a similar functionality without needing to create experiments.
What is the purpose of an experiment now ? Why is it still there if the use case is *covered* by opening multiple traces?
In a scenario when container key are traces/experiement:
Pin strictly concern window range update. View only show data from the container key -> the trace/experiment.
In a scenario when a container is simply a container for signals.
Each view shows data from the trace it was under when opened from the project explorer (this could be a drag and drop mechanism). No possibility to change trace on a per view basis neither for the container since the container have no notion of traces/experiment.
Pin, again, strictly concern window range update.
In both scenario, one selection per trace is a limitation regarding the external support for multi selection of other parts of TC. The easy example of this are the external analysis. Currently they always take the selection from the global context. If we allow multiple selections, it will required an easy way for both the external analysis and the user to identify which selection the user is interested in (e.g. drop down dialog with last selected selection etc.).
This is something that can be fixed.
Two different regions of the same trace? or from multiple traces?
One advantage vs. my proposal is that you wouldn't need to open a second trace instance to view a different window range of the same trace.
Some of the nice things you might lose however vs. my proposal are:
- You can't simultaneously browse the trace events from two different regions, automatically following the selection in each region (you could split the trace editor in Eclipse but good luck scrolling to the right place in a table of millions of events...)
If the same trace, not sure why we could not. Depends on how we handle selection.
If we allow one selection only (per container), you should be able to open N control flow view pin M of them, move O of them and move the selection. If the selection is visible in the windows range it will get displayed.
If we allow multiple selection. I do agree It get tricky.
If for multiple (intersecting) traces and that the container key is a trace, it gets complicated and yes you will need to manual sync between each of them. Since that in my proposition there is no signal exchange between containers.
This is where the notion of a container as a signal group become interesting. Thing is that if there is no visual indicator of such group it is very confusing. The easy way would be a tab or something like it. Each view would need a clear visual indicator of which trace they show data of.
- You can't make two range selections in each region and compare the delta (simultaneously)
What delta ? How can this be handled in your proposition (illustration)?
Back to the top