|Re: [tracecompass-dev] Ideas about pin and new view features|
Hi, On 2016-12-08 06:19 PM, Patrick Tasse wrote:
Hi,On Wed, Dec 7, 2016 at 5:23 PM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@xxxxxxxxxxxx <mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote: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 ? +---------+---------+ | 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).
Above, (*) means the active trace and the views with (*) means they are unpinned and showing the active trace. The other views are pinned to their respective trace.My base use case is that the user has cloned CFV and RV and pinned them to Trace B (on the 'right' side). Then when navigating in CFV-B, the window range of RV-B should follow. When selecting in CFV-B or RV-B the selection follows in CFV-B, RV-B and Trace B.Incidentally CFV-A is pinned while RV-A* and CPUU-A* are unpinned, but since they are showing the same trace, their window range and selection should also follow.If the user makes Trace B active, now he has RV-B* and RV-B showing the same thing, but the user has control, he could have pinned RV-A* to Trace A...For the other use case of browsing two different areas of the same trace, you would for example open Trace A again and get a new instance (A') and then just replace (B) with (A') above.I don't share or understand your concerns here. In the current implementation each trace has its own time range andselection. Those that overlap are synchronized automatically. What is global is the current active trace. So views that showthe 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). "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).Yes of course selection in one trace can influence the trace context of another trace, that is the whole point of the time synchronization between traces.In the absence of any user togglable option, this synchronization was always active. But when there's no overlap it's not really useful, otherwise you always end up at the beginning or end time for the other trace (as you noticed with the bug in the trace editor), so ignoring the external selection in that case was a good compromise.But no point in dwelling on the past if we are going to now allow the user to control the synchronization between traces.
We can have this conversation in meat space someday, it might be easier. Simply taking a note to resume the conversation here if it ever happen.
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).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).
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?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?
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! Thanks for the feedback I guess. Starting with the container might be the way to go here.That's much more involved because all the views have to become viewers, and have their tool bar refactored.
Was referring on the next step toward the future. Regarding the tool bar: there ain't no such thing as a free lunch. I think both proposal here regarding the future will force it at some point.
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. Some nice ideas here. Let me try to understand and compare:So here pin only refers to window-range synchronization of multiple views belonging to the same trace. It's not trace-pinning because trace change wouldn't affect a trace-pinned view anyways (so it wouldn't make sense for a view to have one trace-pin state per trace. It's not time-selection synchronization because you propose only one time selection per trace.
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.
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...)
Two different regions of the same trace? or from multiple traces?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)?
- You can't have two range-pinned views follow each other as you navigate in them. You'd need to add some kind of pin-group controls. In my proposal the trace instance *is* the pin group. This avoids altogether the need to have a separate control of range-pin state per view.
Overall, I think we are headed in the same direction.
Patrick _______________________________________________ tracecompass-dev mailing list tracecompass-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
-- Jonathan R. Julien Efficios
Back to the top