[
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,
Thanks for taking the time to have a reflection regarding the proposed
pin and new instance feature.
I was about to send an introductory email with an RCP containing both
patch sets so everyone could have a test run of those features as
discussed in the previous status meeting. Looks like I wasn't fast
enough. Still, it should be in your mailbox by the end of the day.
On 2016-12-06 06:01 PM, Patrick Tasse wrote:
Hi,
I would like to share some ideas I had that we briefly discussed about
the pin and new view features.
Let my start by stating that the current proposed patch for the pin
feature was demoed to internal users who found it too restrictive.
These users would expect to still be able to navigate a view that has
been pinned.
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.
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).
Furthermore, all such views pinned to the same 'trace' should be
'time' synchronized together permanently.
Again "permanently". This does not look very "flexible".
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.
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
Having multiple traces that are not part of an experiment synchronized
in time is confusing.
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.
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.
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.
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).
With all these views it will be useful to have clear visual indication
of which views are pinned to which trace and/or synchronize together.
In addition to updating the view tab title as is proposed in the
current patches, just an idea,
So far there is a lot of them.
we could use some colors for example in the view/editor border.
In the long term, we envision having a common container for all
views/viewers related to the same trace.
One thing we share.
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)."
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.
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.
When opening traces from under an experiment they could be
automatically time-synchronized with other traces from the same
experiment. (I'm not sure if it would be possible to implement this
well with the pin feature?)
Any thoughts? The end goal is to have a feature that is both flexible,
useful and intuitive.
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.
Cheers
Best regards,
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
