Hi,
On 2016-12-07 03:20 PM, Patrick Tasse wrote:
Hi,
On Wed, Dec 7, 2016 at 9:45 AM, Jonathan Rajotte Julien
<Jonathan.rajotte-julien@xxxxxxxxxxxx
<mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:
As said in the previous status meeting, the proposed patches are
restrictive so we can work our way up while providing a basic
solid way for users to actually compare traces/time range. We are
looking at this feature as a first step in a marathon not the last
one.
For some parts at least, it seems to be more work to be restrictive
so it might be a wasted effort if it's not going to be part of the
end solution.
Yes it might be, again this provide a solid base with minimal quirks.
That being said, I think it might be a good idea to separate
the concept of pinning the 'trace' and pinning the 'time' (for
this discussion pinning 'time' refers to synchronizing both
the window range and the time selection).
When you create a new view instance, it's not really useful to
have the new instance unconstrained by both time and trace.
Otherwise you have two views that show exactly the same thing
(well, you could scroll up and down and have different
filters, but that will be still be possible with my following
suggestion...).
So there is a basic value even without the pin feature. Those two
things are not possible as of today (in the same TC instance).
What I would suggest is that a new view instance should be
pinned by 'trace' permanently.
"pinned by 'trace' permanently.". I would like to disagree here.
By doing that you prevent user from controlling their work flow.
It also add complexity and does not fit in the actual paradigm of
TC (view update based on the active trace).
I wasn't suggesting to make all existing views pinned to a trace,
just the new (cloned?) instances.
Another specific behavior. Less specific behavior more uniform behavior.
It would still have been possible to have a view unpinned (e.g.
following the active trace), but only for one instance of the view.
So let's see how it goes with the current proposal to allow multiple
unpinned view instances.
There is value there, not for all views but for all those that have
vertical/internal states.
However, I'm still thinking that we might want to decouple the
controls for pinning (to a trace) and synchronizing (to time). More
below.
Furthermore, all such views pinned to the same 'trace' should
be 'time' synchronized together permanently.
Again "permanently". This does not look very "flexible".
This requirement I feel should stay, as it seems intuitive and in
line with the current design. The trace manager has a context per
trace instance (which has the window range and time selection), and
all views and editors that show that trace instance (whether they are
pinned to the trace or unpinned while that trace is active) are
time-synchronized.
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 ?
This is actually the use case that triggered me to start this thread...
So for example if you have two traces opened, Trace A and
Trace B. Trace A is the active trace and Control Flow view
(CFV) and Resources view (RV) show Trace A. If you create a
new instance of CFV, you somehow have to decide which trace it
should be pinned to, let's say Trace B in this example.
What would be the "somehow" ? In the proposed feature it is
simple: it always sync with the global context since a new view
instance is not pinned.
I was thinking a "New View" sub-menu or subsequent dialog, but let's
try it as proposed with a togglable pin to trace.
Now you have CFV-B and you pin it in 'time' so that it is no
longer synchronized with Trace A.
CFV-B is linked with Trace B but synchronized in time with trace A
? This all boils down to the discussion going on here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=508332
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=508332>
Having multiple traces that are not part of an experiment
synchronized in time is confusing.
I disagree that it's confusing if it's what you want, but perhaps it
is not what *you* (or some users) want or expect. I'm open to the
idea of having this synchronization off by default, but I think it
should always be an option available to the user, without having to
create experiments.
If you then create a new instance of Resources view RV-B
pinned in 'time', I don't think we want to have three
independent time selections.
You just hit the main problem. Multi-selection is an
out-of-your-mind idea for the current Trace Compass paradigm.
Some part always query the global state and would not care about
the pin notion.
A solution to that is to mutate the notion of global context to a
notion of last encountered context and provide a list of possible
selections when it is necessary.
This is no small changes but can be done incrementally and is one
the main reason that the proposed features are restrictive
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).
You would have to manually browse in CFV-B and RV-B separately
to keep them aligned. Hence the proposal to have CFV-B and
RV-B permanently time-synchronized. And they would also be
time-synchronized with their pinned trace Trace B so that you
could correlate the trace events with the selection in those
views.
Then what happens to the pinning by 'time'? I think this
should be a state of that trace instance. Trace B is either
pinned to its own time, or it is time-synchronized with the
other unpinned traces.
I will reiterate my disagreement here regarding time
synchronization across intersecting traces/experiments. There is
little reasons for two experiments/traces to synchronize
themselves in time if one is considered inactive (not shown to the
user) and the other active. It is simply confusing for users that
most of the time do not work on intersecting traces and expect a
state for one trace/experiment and a separate state for the non
active traces/experiments. The day they get intersecting traces
and try to do dual selection on both to compare, all of a sudden
they get the same state for both trace. This is simply complicated.
Keep in mind that the inactive traces can still be shown to the user
through the trace editor. It's just the graphical views that
currently only show the active trace.
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!
This propagates to all the views that are trace-pinned to that
trace instance. The control of time-pinning should be
available also from the trace editor and kept in consistent
state with the views.
One future possible incremental change was to introduce the notion
of pinning groups. In a pinned group you receive signal and
broadcast to the group.This would change the behavior of TC in a
major way. Here we are doing baby steps while fulfilling a basic
user need: comparing two or more CFV/RV visually in the same
eclipse instance and at possibly two or more different visual time
ranges.
It sounds like a good feature to allow customizing the pinning
groups. The current implementation behaves a bit like an automatic
pinning group: traces that overlap are in the same pinning group and
this cannot be avoided. The proposed pin feature now allows the user
to opt-out of that pinning group.
I would propose to have a change of terminology to go along with my
suggestions: if we restrict 'pinning' to the trace (e.g. pinning is
fixing the trace for that view), we can have a separate control to
'synchronize' the trace in time with other traces. And perhaps
synchronizing could be an opt-in instead of an opt-out. However this
would be a change of default functionality for current users.
Let us now consider the case of a user that wants to view two
different window ranges of the same trace. When creating a new
view instance, the user would choose the same trace that is
currently shown in the original view. This would create a new
instance of the trace and open it in its own editor. This
would allow the user to view and synchronize the trace events
of the two examined regions concurrently, e.g. CFV-A(1)
synchronized with Trace A(1) and CFV-A(2) synchronized with
Trace A(2).
I wasn't sure how to handle this now, but I thought of a simple
solution: Currently when we 'open' a trace that is already opened, it
only makes that editor active. All that would be required if a user
wants to browse two different areas of a trace, would be to open it
twice (and get two editors). Then each trace instance has its own
context, and each instance's views are synchronized together.
Obviously here it would make sense to have time synchronization off
by default in the new instance...
A use case that this allows, is a user that wants to view two
different areas of the same trace in CFV for example, might also want
to concurrently see the corresponding trace events for each area.
Having two separate trace editors opened allows that.
With regards to the ongoing discussion about time
synchronization, now that we are implementing a pin feature we
could have time-synchronization being an opt-in instead of an
opt-out. All that is required is to have the pinned state set
by default when opening a trace (or it could be a user
preference).
Wasn't time synchronization a promoted feature ?
" Because this time synchronization of two or more opened traces
is a promoted feature of the tool since the very beginning (before
it was Trace Compass)."
My point was that time synchronization shouldn't be removed as a
feature because some users still want it. I'm trying to accommodate
both sides by perhaps having it off by default. I'm not sure what
your point was?
The point was: one second time-synchronization is a promoted feature
the other it become an opt-in.
Some other ideas that the above design could enable (the devil
is in the details):
Actually there is code currently that most probably deal with 80
to 90 % of use case regarding all of this without reimplementing TC.
The main problem regarding the pin feature is actually how to deal
with multi selection in multiple pinned view. Otherwise other
features regarding visual time range can be enabled. More infos in
the RFC email.
I think my suggestions deal nicely and intuitively with time
selection of multiple trace instances: one trace instance = one time
selection, and the 'synchronization' toggle controls whether these
time selections affect each other.
Must have missed the "'synchronization' toggle controls" the first
time. Could be a solution. I still believe this a feature for an
experiment/trace collection.
When opening a view from the Window > Show View menu, you would
get the unconstrained view (the one without a secondaryId) that
follows the active trace. But when you open a view from the
Project Explorer 'Views' subtree under the trace, you would get a
view that is automatically pinned to that trace.
When closing a trace it would automatically close all views
that are pinned to that trace.
Moving away from the eclipsy/ide paradigm. Bold move.
That seemed like the only option that made sense in my original
suggestion where cloned views were permanently pinned to a trace
instance.
Otherwise, there are more options, I'm not sure which is more intuitive?
- Close the pinned views
- Unpin the pinned views unconditionally (possibly leaving multiple
unpinned views showing the same trace)
- Unpin the pinned views if there exists no corresponding unpinned
view instances, otherwise close the pinned views (leaving at most one
unpinned view)
With a togglable pin it would always be possible to have multiple
unpinned views, so it's really just a question of automatically
cleaning up the workbench or not.
Thinking about the future enhancement of having a common container
for all views related to a trace instance, then closing the pinned
views would mean that closing the trace would be akin to closing that
future container.
Starting with the container might be the way to go here.
We can put the current patch set on hold while you prepare a
working prototype of all this. I'm having a hard time picturing
all of this.
I'll still make sure to provide multiple versions of the proposed
pin feature: restrictive and one with all features except those
touching the current selection.
I would propose as a first step to have a patch set where pinned
views are isolated from external synchronization but without any
navigation restrictions.
Will try my best to it. But selection is still a challenge.
Then the possible next steps could be (I'm not sure in which order):
- Split trace-pinning and time-synchronization control
- Have time-synchronization from same trace instance apply
unconditionally (I guess this requires trace instance in the signal)
- Allow multiple trace instances of same trace opened at same time
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)