On Thu, Dec 22, 2016 at 11:11 AM, Jonathan Rajotte Julien
<Jonathan.rajotte-julien@xxxxxxxxxxxx
<mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:
Hi,
On 2016-12-10 05:02 PM, Patrick Tasse wrote:
Hi,
On Fri, Dec 9, 2016 at 4:27 PM, Jonathan Rajotte Julien
<Jonathan.rajotte-julien@xxxxxxxxxxxx
<mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:
+---------+---------+
| 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).
The way I envisioned it was that the containers would be
workbench parts that allowed dockable widgets to be organized
in their layout. All the viewers inside would be linked to the
same trace instance and time-synchronized in window range and
selection together.
As discussed in meat space. We agree on the "workbench parts that
allowed dockable" part, less on what would be the signal key for
synchronization (trace, parent workbench, etc.) and what would be
allowed inside this container (widget linked to different trace,
etc.).
A good start would be to decide what would be the signal key. For
now, the obvious choice would be the trace object since most
signal already carry it in a way or another.
So you would need two containers to browse two different
traces at the same time, or two containers to browse two
regions of the same trace (using two different trace instances).
I would see them as editor parts, just an expansion of the
current trace editor, but containing possibly more widgets
than the single one it has today (the event table).
The existing views (e.g. Control Flow view) being converted to
viewers could easily exist within the trace editor or their
own views, unpinned to active trace or pinned to a specific
trace. I mean that it would be easy to implement as views
after they have been converted to viewers, but I'm not saying
that we would necessarily want to allow that.
+-------------------+
| CPUUV-A* |
+---------+---------+
| CFV-A | |
| ------- | CFV-B |
| RV-A | |
| ------- | ------- +
| Trace A*| Trace B |
+---------+---------+
Above would be two containers, one for Trace A and one for
Trace B, the container for Trace A is active, and the unpinned
CPUUV is showing active Trace A.
CFV-A, RV-A and Trace A are time-synchronized together, by
their trace instance. The trace instance lives or dies in
accordance with its container's editor part.
A synchronization toggle control could determine if the
different containers (trace instances) are time-synchronized
together.
To browse another region of Trace A, open a new instance in
its own editor container (replace B with A' above).
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).
No, I'm not sure I understand?
By 'this' I mean your current patch sets but without the
navigation restrictions? So you could get a new view instance
and pin it to a trace isolated from time-synchronization. You
would be able to browse the trace manually.
By 'short term' I assume just until a following patch which
would enable time-synchronization (of pinned views showing the
same trace as the new window range or selection source?).
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?
It allows the merging of traces into a single trace. Initially
we thought of traces of different types or different sources,
but we also later discovered the case of a trace that was
split into multiple trace files for disk usage considerations,
it merges back together nicely in an experiment.
There were also some features developed specifically with
experiments in mind, like the trace synchronization (the
feature that computes a time offset by algorithm based on
matching trace events from different traces), and the VM
analysis, I believe.
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.
I see the problem, whether you have multiple 'selection
context' on same trace instance or single selection on
multiple trace instances (of the same trace), which are you
referring to when you click the single trace element in the
Project Explorer (to run an analysis or open a dependent view)?
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.
I was referring only to the event table in the trace editor,
if there is only one instance per trace.
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)?
I just meant measuring two ranges simultaneously that wouldn't
be possible if there was only one selection per trace (and
only one trace instance).
As of today, if I remember, TC does not allow this?
I guess ultimately two trace instance of the same trace or two
'selection contexts' of the same instance could be the same
thing, but maybe for backward compatibility and maybe it would
be a simpler implementation if it's just another instance of
ITmfTrace vs. every user now having to know about trace
'selection context'?
Conclusion from the meat space interaction.
Regarding the current proposed patch set, two additional RFC patch
set will be produced to evaluate the UX and functionality. Those
will be based on the current patch set as of today. Implementation
details regarding how to scope the feature in the code (TmfView
wide feature, Interface, etc.) will be leaved for when we have a
consensus on the UX.
The first one will allow user to navigate but will deactivate
everything implicating selection. The view will be isolated
regarding selection. No selection will be permitted inside the
viewer and no selection indicator will exist for the pinned view.
This allow the view to be completely isolated and will allow
multiple view with different trace.
The second one will allow navigation and selection. Selection made
inside the pinned view will propagate to other view and selection
made by other view will be propagated to the pinned view. When
pinned a control flow/resource view will not seek to show update
of selection.
Cheers
Patrick
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx <mailto: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
<https://dev.eclipse.org/mailman/listinfo/tracecompass-dev>
--
Jonathan R. Julien
Efficios
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx <mailto: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
<https://dev.eclipse.org/mailman/listinfo/tracecompass-dev>
_______________________________________________
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
