Trace Compass/Design Documents/Project View

This page presents a proposal to reorganize the Project View and Trace Compass projects

Current implementation

There are various limitations to the current implementation:

• A Trace Compass project type is required. This makes it hard to integrate with other project types, for example opening traces while working in a CDT project. Only adding the project nature does not seem to work.

See the discussion in https://dev.eclipse.org/mhonarc/lists/tracecompass-dev/msg00412.html

• Experiments are second-class citizens. Most analyses do not work with experiments, only with single traces. Also the name "experiment" is not particularly intuitive.
• Analyses are listed under the trace. This is useless information for the user, and clutters the view. The list of views however is useful for the user.
• A new type of "on-demand" analysis is coming up. Unlike our standard "dynamic" analyses, these new on-demand ones will require user interaction. How should they be presented to the user?

Proposal

The proposal consists of reorganizing the Project View hierarchy into the following one:

- (Eclipse Project)
  +- Trace Collection 1
    +- Traces
      +- Trace 1
      +- Kernel Trace 2
      +- Kernel Trace 3
    +- Bookmarks
    +- Analyses
      +- Lttng-Analyses IO Top
      +- Lttng-Analyses Frequency Top
      +- Custom Analysis A
    +- Reports
      +- Frequency Top 1
      +- Frequency Top 2
    +- Views
      +- Control Flow view
      +- Resource view
      +- CPU Usage view

Trace Collection as the base element

"Experiment" would be renamed to Trace Collection, or Trace Set. This would be a new type of resource that could be part of any Eclipse project. There would always be a trace set, even for only one trace (although importing a single trace could create the trace set automatically).

The whole Trace Compass project type would be removed.

Traces

The Traces sub-tree would simply be the list of traces present in the trace set, just like traces are currently part of experiments.

Adding/removing traces after analyses have been run and reports generated would have to be thought about. Mark the relevant reports "dirty"?

Bookmarks

The current concept of bookmarks would be extended to apply to the whole trace collection. This way, existing bookmarks could point to locations in new traces in the collection as they are added.

Analyses

The list of on-demand analyses the user can run, which will generate reports.

Very important to note: this sub-tree would be used to list the on-demand analyses, like the LTTng-Analyses integration. The previous list of dynamic analyses would be removed (only the views are kept).

Reports

Reports are the output of on-demand analyses. As analyses are run, reports are generated and added to this list. The user can then open them, export them, delete them, etc.

A report can be a view or a set of view that contain the results of the analysis that was run.

Views

The list of views that can show information about this trace. These elements exist currently, but are located under the name of the analysis that populates them.