Re: [tracecompass-dev] Separating ITmfTrace from the UI

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

Hey Genevieve,


That is absolutely true, but I think it's mostly in time sync, no? and
in core. I would say it is a separate patch, but I will already be in
that frame of mind, so please review one if you see it coming in. :)


Matthew


On 17-12-14 04:09 PM, Geneviève Bastien wrote:
> Hi Matthew,
>
> Thanks for doing this!
>
> If I may add, while you're at it... In some places (I don't have
> anything in mind), ITmfTrace is used where the host ID should be used.
> Host ID is a way to identify traces taken on a same machine, ie whose
> timestamp we can match together and their CPUs/threads/etc are the same.
>
> Maybe in some places, instead of simply switching ITmfTrace to UUID,
> it may be worth looking at using host ID. I'm thinking symbol
> providers actually for such an example, where kernel and/or UST and/or
> perf traces from that host may contain symbols representing the same
> things.
>
> Geneviève
>
>
> On 12/14/2017 03:59 PM, Matthew Khouzam wrote:
>>
>> Hello world, Part of separating the UI from the Core of Trace Compass
>> is to remove all instances of ITmfTrace from all viewers.
>> This entails several potential modifications.
>> ## How is ITmfTrace used in UI?
>> The trace is mostly used as a key in the viewer. It is mostly used in
>> "trace opened" to check if the viewer already has the trace opened?
>> There are places where the trace is needed though, it appears to be
>> used for:
>> - Get next event (control flow view) (should be fixed with data provider)
>> - Get trace names in timegraph (Gantt) views and XY plot views?
>> (should also be fixed with data providers)- Make sure nothing breaks. :)
>> ## What are the first steps to decoupling this?
>> I would suggest the following steps:
>> 1. Deprecate getActiveTrace and getActiveContext. This is optional
>> but super recommended
>> 2. Overhaul TmfTraceManager to handle UUIDs instead of ITmfTrace as a key
>> 3. Overhaul TmfTraceUtils to handle UUIDs instead of ITmfTrace as a
>> key4. Add shims in DataProviderManager to handle UUIDs instead of
>> ITmfTrace as a key5. Create a temporary DataproviderManager shim so
>> all views go though one.6. Change symbol provider to handle UUIDs
>> instead of ITmfTrace as the key.7. Update project explorer model to
>> require UUIDs rather than ITmfTrace. Tricker but actually quite
>> isolated.8. Make traces register automatically in the
>> TmfTraceManager9. Maybe add the trace name to the trace context if
>> need be
>> ## What about the API?
>> Old API will be deprecated, but available for a year.
>> ## When should these changes be done?
>> We are aiming for this to be done for Trace Compass 4.0
>> ## How much work will it be?
>> Short answer: Lots. More details:There will probably be over a dozen
>> patches + incubator patches on Gerrit that will touch over 50
>> classes. To give an idea, ITmfTrace is referenced over 1900 times in
>> trace compass with the incubator.The goal is to decouple every
>> package ending in ui from ITmfTrace, not just tmf.ui. One of the
>> bigger violators is analysis.ui, luckily it uses the trace in the
>> same way in many classes.
>>  
>> ## I need help updating my plug-in to work with the new way of working?
>>  
>> Email us, or open a bug, we like helping PS. this is a draft, feel
>> free to poke holes in it, there are surely some use cases that are
>> missed.
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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