Re: [tracecompass-dev] UI for external analyses

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

> > Also, there appear to be a terminology issue with automatic vs on-demand
> > analyses, external analyses, etc. So it would be important to define
> > those terms. Right now, we have 2 types of analyses:
> >
> > * Automatic: Run whenever a trace is opened, it does not wait for a view
> > or user action to schedule it
> > * On-demand (automatic set to false in extension point): Some other
> > action schedules the analyses, like opening a view, or selecting an
> > entry in a view.
> >
> >  From your first post, there seems to be an orthogonal concept of static
> > vs dynamic analyses:
> >
> > * Dynamic: follow user action, time ranges, etc
> > * Static: Generated once on the whole trace or time range and that's it.
> > That is where your "external analyses" fit. Why not call them simply
> > "reports" or "analysis reports".
> >
> > So in your tree up there, you would have "Analyses" (both automatic and
> > on-demand) and "Reports" (on-demand, but could also be automatic) for
> > static external analyses.
>
> Yep as I explained in my reply to Bernd, it is orthogonal to the 
> current notion of on-demand/lazy-loaded analyses. "Static analysis" is 
> not bad, though I'm not sure if it's intuitive enough...
>
> You are right about the reports, we should also display them somewhere 
> so that they can be re-opened, deleted, managed in some way. However, 
> don't forget it's possible to run the same analysis multiple times to 
> get different reports, like in the example above. So we would need 
> both, the list of analyses that can be run, and the reports that were 
> generated. What would be the best way to show them?
>
>
> trace
>  +- Automatic/Dynamic analyses
>  |   +- Kernel analysis
>  |   +- CPU Usage analysis
>  +- On-demand/Static analyses
>      +- LTTng-Analyses CPU Top
>      |   +- Report 1
>      |   +- Report 2
>      +- LTTng-Analyses IO Top
>      |   +- Report 1
>      +- Critical Path analysis
>          +- Report 1
>
>
>
> or rather
>
> trace
>  +- Automatic/Dynamic analyses
>  |   +- Kernel analysis
>  |   +- CPU Usage analysis
>  +- On-demand/Static analyses
>  |   +- LTTng-Analyses CPU Top
>  |   +- LTTng-Analyses IO Top
>  |   +- Critical Path analysis
>  +- Reports
>      +- CPU Top Report 1
>      +- CPU Top Report 2
>      +- IO Top Report 1
>      +- Critical Path Report 1
>
>
>
> ?

I discussed this a bit more with some colleagues, and and we realized 
the list of Dynamic analyses is not really useful for the end-user ; 
what they use is the list of Views they can open, which are shown 
currently under each analysis they belong to. But the user doesn't have 
to know that the Control Flow view comes from the Kernel analysis, they 
are only interested in the output.

So, what if we stopped showing the (dynamic) analyses altogether? A big 
advantage is that we could use the name "Analysis" for the only type of 
analyses the user will care about: the static ones! So the tree could 
look like this:



trace
 +- Views
 |   +- Control Flow view
 |   +- Resource view
 |   +- CPU Usage view
 +- Analyses
 |   +- LTTng-Analyses CPU Top
 |   +- LTTng-Analyses IO Top
 |   +- Critical Path analysis
 +- Reports
     +- CPU Top Report 1
     +- CPU Top Report 2
     +- IO Top Report 1
     +- Critical Path Report 1


In the code we could still refer to dynamic/static analyses, but the 
only analyses we would show to the user would be the static ones, since 
they are the only one they can act upon. How does it sound?

Cheers,
Alex