Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Ideas about pin and new view features


On 2016-12-07 03:20 PM, Patrick Tasse wrote:

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

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

    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:

    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

        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

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

    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:

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) under the container. How to deal with multi selections is an open question. One solution is to allow selection inside a pinned view and all views not pinned sync to it (as usual). A selection made outside of pinned view (another pinned view or any view) would update the selection inside of the pinned view but does not update the visual time range (for visual windows base view). You end up with always one selection.

So from this end goal what do we do now with the current proposed features.

Pin become a view state like filters and other view states. On trace change we simply fetch the previous state related to this view/trace tuple and if it was pinned simply populate the pin state (signal blocking etc.) This allow user to have multiple views of the same type (Control flow view, resource view) on different visual time range etc. but does not allow comparison between traces. It remove ambiguity regarding what belongs to what and would fit better in the end goal. It prevent us from exposing a feature to a user that will probably not be useful in the end.

So for short term goals:

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

-> Investigate the most permissive pinning policy for CFV and RV.
-> Change the pin behavior regarding trace changes. Migrate the pin to a per trace view state.
-> Figure out how to handle selection in a pinned view.

Obviously I will postpone the introductory email a little bit.



tracecompass-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Jonathan R. Julien

Back to the top