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-23 07:01 PM, Patrick Tasse wrote:
Hi Jonathan,

I'm not sure if the second option is the same that I'm proposing.

I did some cherry-picking of the parts of your patch set that I needed and modified/added the functionality I'm envisioning, so we can evaluate it as a third option.

So as not to bloat gerrit I squashed everything into a single commit [1], but I have the branch locally. The code is not complete

What would be missing ?

and not tested but it gives a good idea of my proposal when using multiple CFV/RV each pinned to their own trace, which could be a different instance of the same trace or a different trace altogether.

I tried it with this layout. In that use case the views/editors in the same column were selection and window range synchronized.

|  CFV-A  |  CFV-B  |  CFV-B' |
|  RV-A   |  RV-B   |  RV-B' |
| Trace A | Trace B | Trace B' |

Where Trace is an event table representing a trace.



Had some fun with it yesterday morning here my initial feedback.

I understand the necessity (implementation wise) of spawning a new editor each time a view get "opened" from the project explorer but oh boy is it confusing. All editors have the same name. It get even more confusing the moment you want to compare the same trace (N control flow view).

If I understand correctly the work flow would be to open two times the control flow view from the project explorer then activate one of the 2 spawned editors to gain active trace status, pin one of the control flow view, activate the other tab and pin. The other way is to clone control flow view then open another event table and redo half the stuff listed above. This also introduce asymmetry between the new view feature, which do not spawn event tables, and the open from project explorer, which spawn event tables.

To be honest, I'm not fond of it. The fact that multiple event tables have the be spawned to play in the same trace is for me a problem since, for now, there is no visual indication of link between them and their corresponding view. Are those new event tables treated like standalone instances of a trace object (Trace open/close)?

In the end, this is only an opinion, could you upload an RCP for others to try? I know most of them are devs but it might help having feedback. The more eyes we have on this the better.

This is something that was already brought up but discussing with Julien Desfossez, we found a functional implementation of grouping in Terminator [1]. More information on the grouping feature in here [2](section 1.6 p42). This would require a rework of the notion of opening a trace and closing it. A direct equivalent from Eclipse would the notion of opening a project or closing it.



On Thu, Dec 22, 2016 at 11:11 AM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@xxxxxxxxxxxx <mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:


    On 2016-12-10 05:02 PM, Patrick Tasse wrote:


        On Fri, Dec 9, 2016 at 4:27 PM, Jonathan Rajotte Julien
        <mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:

                |  CFV-A  |  CFV-B  |
                |  RV-A*  |  RV-B   |
                |       CPUU-A*     |
                | Trace A*| Trace B |

                OK, I'm making this more complicated than my original
        use case
                so that we can foresee potential issues:

            Not sure I got all of this but let's say you have the
        notion of
            container (pick your poison here) how does this could be
            (illustrate if you can).

        The way I envisioned it was that the containers would be
        workbench parts that allowed dockable widgets to be organized
        in their layout. All the viewers inside would be linked to the
        same trace instance and time-synchronized in window range and
        selection together.

    As discussed in meat space. We agree on the "workbench parts that
    allowed dockable" part, less on what would be the signal key for
    synchronization (trace, parent workbench, etc.) and what would be
    allowed inside this container (widget linked to different trace,

    A good start would be to decide what would be the signal key. For
    now, the obvious choice would be the trace object since most
    signal already carry it in a way or another.

        So you would need two containers to browse two different
        traces at the same time, or two containers to browse two
        regions of the same trace (using two different trace instances).

        I would see them as editor parts, just an expansion of the
        current trace editor, but containing possibly more widgets
        than the single one it has today (the event table).

        The existing views (e.g. Control Flow view) being converted to
        viewers could easily exist within the trace editor or their
        own views, unpinned to active trace or pinned to a specific
        trace. I mean that it would be easy to implement as views
        after they have been converted to viewers, but I'm not saying
        that we would necessarily want to allow that.

        |      CPUUV-A*     |
        |  CFV-A  |         |
        | ------- |  CFV-B  |
        |  RV-A   |         |
        | ------- | ------- +
        | Trace A*| Trace B |

        Above would be two containers, one for Trace A and one for
        Trace B, the container for Trace A is active, and the unpinned
        CPUUV is showing active Trace A.

        CFV-A, RV-A and Trace A are time-synchronized together, by
        their trace instance. The trace instance lives or dies in
        accordance with its container's editor part.

        A synchronization toggle control could determine if the
        different containers (trace instances) are time-synchronized

        To browse another region of Trace A, open a new instance in
        its own editor container (replace B with A' above).

                If we have an initial version with no
        time-synchronization of
                pinned views, I don't think it needs to be delayed
        while we
                figure out how to control and apply the trace

            I do agree here. But you understand that this (no
            time-synchronization of pinned views) imply that in the
        short term
            a user will not be able to compare graphical views between
            (same as of now).

        No, I'm not sure I understand?

        By 'this' I mean your current patch sets but without the
        navigation restrictions? So you could get a new view instance
        and pin it to a trace isolated from time-synchronization. You
        would be able to browse the trace manually.

        By 'short term' I assume just until a following patch which
        would enable time-synchronization (of pinned views showing the
        same trace as the new window range or selection source?).

                Initially the purpose of an experiment was to merge
                traces into one chronologically, at a stage where
        there could
                only be one trace/experiment opened at a time. It's when
                support for multiple opened traces was added that
                time-synchronization of traces was implemented, to
        provide a
                similar functionality without needing to create

            What is the purpose of an experiment now ? Why is it still
            if the use case is *covered* by opening multiple traces?

        It allows the merging of traces into a single trace. Initially
        we thought of traces of different types or different sources,
        but we also later discovered the case of a trace that was
        split into multiple trace files for disk usage considerations,
        it merges back together nicely in an experiment.

        There were also some features developed specifically with
        experiments in mind, like the trace synchronization (the
        feature that computes a time offset by algorithm based on
        matching trace events from different traces), and the VM
        analysis, I believe.

            In a  scenario when container key are traces/experiement:
                Pin strictly concern window range update. View only
        show data
            from the container key -> the trace/experiment.

            In a scenario when a container is simply a container for
                Each view shows data from the trace it was under when
            from the project explorer (this could be a drag and drop
            mechanism). No possibility to change trace on a per view basis
            neither for the container since the container have no
        notion of
                Pin, again, strictly concern window range update.

            In both scenario, one selection per trace is a limitation
            regarding the external support for multi selection of
        other parts
            of TC. The easy example of this are the external analysis.
            Currently they always take the selection from the global
            If we allow multiple selections, it will required an easy
        way for
            both the external analysis and the user to identify which
            selection the user is interested in (e.g. drop down dialog
            last selected selection etc.).
            This is something that can be fixed.

        I see the problem, whether you have multiple 'selection
        context' on same trace instance or single selection on
        multiple trace instances (of the same trace), which are you
        referring to when you click the single trace element in the
        Project Explorer (to run an analysis or open a dependent view)?

                One advantage vs. my proposal is that you wouldn't need to
                open a second trace instance to view a different
        window range
                of the same trace.

                Some of the nice things you might lose however vs. my
                - You can't simultaneously browse the trace events
        from two
                different regions, automatically following the
        selection in
                each region (you could split the trace editor in
        Eclipse but
                good luck scrolling to the right place in a table of
                of events...)

            Two different regions of the same trace? or from multiple

            If the same trace, not sure why we could not. Depends on
        how we
            handle selection.
            If we allow one selection only (per container), you should
        be able
            to open N control flow view pin M of them, move O of them
        and move
            the selection. If the selection is visible in the windows
        range it
            will get displayed.

        I was referring only to the event table in the trace editor,
        if there is only one instance per trace.

            If we allow multiple selection. I do agree It get tricky.

            If for multiple (intersecting) traces and that the
        container key
            is a trace, it gets complicated and yes you will need to
            sync between each of them. Since that in my proposition
        there is
            no signal exchange between containers.

            This is where the notion of a container as a signal group
            interesting. Thing is that if there is no visual indicator
        of such
            group it is very confusing. The easy way would be a tab or
            something like it. Each view would need  a clear visual
            of which trace they show data of.

                - You can't make two range selections in each region and
                compare the delta (simultaneously)

            What delta ? How can this be handled in your proposition

        I just meant measuring two ranges simultaneously that wouldn't
        be possible if there was only one selection per trace (and
        only one trace instance).

    As of today, if I remember, TC does not allow this?

        I guess ultimately two trace instance of the same trace or two
        'selection contexts' of the same instance could be the same
        thing, but maybe for backward compatibility and maybe it would
        be a simpler implementation if it's just another instance of
        ITmfTrace vs. every user now having to know about trace
        'selection context'?

    Conclusion from the meat space interaction.

    Regarding the current proposed patch set, two additional RFC patch
    set will be produced to evaluate the UX and functionality. Those
    will be based on the current patch set as of today. Implementation
    details regarding how to scope the feature in the code (TmfView
    wide feature, Interface, etc.) will be leaved for when we have a
    consensus on the UX.

    The first one will allow user to navigate but will deactivate
    everything implicating selection. The view will be isolated
    regarding selection. No selection will be permitted inside the
    viewer and no selection indicator will exist for the pinned view.
    This allow the view to be completely isolated and will allow
    multiple view with different trace.

    The second one will allow navigation and selection. Selection made
    inside the pinned view will propagate to other view and selection
    made by other view will be propagated to the pinned view. When
    pinned a control flow/resource view will not seek to show update
    of selection.



        tracecompass-dev mailing list
        tracecompass-dev@xxxxxxxxxxx <mailto:tracecompass-dev@xxxxxxxxxxx>
        To change your delivery options, retrieve your password, or
        unsubscribe from this list, visit

-- Jonathan R. Julien

    tracecompass-dev mailing list
    tracecompass-dev@xxxxxxxxxxx <mailto:tracecompass-dev@xxxxxxxxxxx>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit

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