Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Separating ITmfTrace from the UI
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 key
4. Add shims in DataProviderManager to handle UUIDs instead of ITmfTrace as a key
5. 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 TmfTraceManager
9. 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

Back to the top