| Re: [tracecompass-dev] Ideas about pin and new view features |
It make this probably common use case easy for the user: If you create new CFV and RV instances and pin them to Trace B, then they are time-synchronized together, and with their corresponding trace event table
Not sure what is the use case here. Could you illustrate it ?
"If they do not overlap" is the major problem here. You start by saying: "In the current implementation each trace has its own time range and selection" but you follow with "if they overlap" you share the selection for both of them. What I'm having a problem with is that selection can influence trace context that do not belong to the active trace. It may or may not happen (intersect or not).I don't share or understand your concerns here. In the current implementation each trace has its own time range and selection. Those that overlap are synchronized automatically. What is global is the current active trace. So views that show the global active trace can get that specific trace's time range and selection, it is not a random or undetermined (i.e. confusing) selection. You currently can have two trace editors opened side-by-side and they each have their own selection (if they do not overlap).
Let's hope this get resolved ASAP and we find a way toward showing multiple trace at the same time in multiple views. It might be just the graphical view but they are 98% of the reason users use trace compass otherwise they would be using Babeltrace (regarding ctf and lttng).
So automatic trace synchronization is apparently not something you want, but you have to be open to the idea that for some users it might be the only reason they use the tool. They might have two custom text logs that create no graphical view whatsoever, they just want to open them both and browse them together, keeping the trace editors synchronized. They currently can do this without having to bother about experiments.
No it is not something I want when they are not under an experiment. What is the purpose of an experiment?
>From the user doc:
"An experiment consists in an arbitrary number of aggregated traces for purpose of correlation. In the degenerate case, an experiment can consist of a single trace. The experiment provides a unified, time-ordered stream of the individual trace events."
Seems like a good fit here. Maybe the experiment part of Trace Compass is missing some love ?
I hope they heard of vim, emacs and other text viewer that most probably do a better job than TC at having split view for text, they even support offset scroll binding these day!
Starting with the container might be the way to go here.
>From a meeting this morning here at EfficiOS:
Let's say we draw the final form we would like: http://donot.review/up/tc/rfc/tc-ui-per-trace.txt
Lots of missing scenario but most of them should work okai and we think it addresses most of your concern.
As you probably observed we share a common goal and maybe other aspects: a sort of container. Here a trace but could be a trace collection, notebook, workgroup. Interactions do change based on what is the container.
"Trace" limits the content to view showing information about the trace, same for experiment/trace collection. Notebook and workgroup could be more flexible and allow multiple views showing different traces data etc.
In all cases signals would be restricted to the container. The event table become another view.
Where does pin fit in this scenario? A pinned view inside the container would simply stay under the container and act on its own (time wise) under the container. How to deal with multi selections is an open question.
One solution is to allow selection inside a pinned view and all views not pinned sync to it (as usual). A selection made outside of pinned view (another pinned view or any view) would update the selection inside of
the pinned view but does not update the visual time range (for visual windows base view). You end up with always one selection.
So from this end goal what do we do now with the current proposed features.
Pin become a view state like filters and other view states. On trace change we simply fetch the previous state related to this view/trace tuple and if it was pinned simply populate the pin state (signal blocking etc.)
This allow user to have multiple views of the same type (Control flow view, resource view) on different visual time range etc. but does not allow comparison between traces.
It remove ambiguity regarding what belongs to what and would fit better in the end goal. It prevent us from exposing a feature to a user that will probably not be useful in the end.