Re: [tracecompass-dev] Ideas about pin and new view features

[Patrick Tasse <patrick.tasse@xxxxxxxxx>]

Hi,

On Wed, Dec 7, 2016 at 9:45 AM, Jonathan Rajotte Julien <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.

 

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. 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.

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.

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

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).

 

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.

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.

 

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?

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.

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.

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.

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

Patrick