|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.
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
Back to the top