[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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 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).
"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
