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

[Patrick Tasse <patrick.tasse@xxxxxxxxx>]

Hi,

On Fri, Jan 6, 2017 at 11:09 AM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@efficios.com> wrote:

What would be missing ?

Fixing the tests, updating documentation, did not address all of my own comments on the other patch set, and try to help the user identify what syncs with what, etc.

 

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

Very true. I made an additional change where the trace manager keeps track of sequential instance numbers of the same trace. So if you open the same 'trace' multiple times, the instances are named 'trace', 'trace | 2', 'trace | 3' and so on. So no change if you open it only once. The sequence resets if you close all opened instances of that particular trace.

I've had feedback that double-clicking on project explorer maybe should not open a new instance automatically. Maybe it could be a context menu action instead on the trace in Project Explorer.

Or maybe something in the view menu to make it simpler for user e.g. 'New Control Flow view on this trace' would automatically open the new instance and pin to it.

 

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.

I had another idea that the pin button could be a drop-down button (like the Run button). So pushing the button would pin to the active trace (or unpin), but opening the drop-down you could choose from any of the opened traces and pin to it immediately, without having to first make that trace active. It would also allow the user to easily switch the trace of a pinned view.

I added this functionality to my patch set.

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.

 

It's not perfect but it allows most (all?) use cases. We can build on it to make it more intuitive for the user.

Are those new event tables treated like standalone instances of a trace object (Trace open/close)?

Yes exactly. And they have their own trace context (window range, time selection) in the trace manager.

 

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.

Interesting. I don't think we can control the color of the title bar/tabs of views and editors in Eclipse, but these would really help to understand what synchronizes together.

Patrick