[
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-10 05:02 PM, Patrick Tasse wrote:
Hi,
On Fri, Dec 9, 2016 at 4:27 PM, Jonathan Rajotte Julien
<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
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
