[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] UI for external analyses
|
Hi Alex,
Sorry to come in late in that discussion. Here are my thoughts:
On 02/19/2016 02:59 PM, Alexandre Montplaisir wrote:
>
>
> On 2016-02-18 11:01 AM, Bernd Hufmann wrote:
>> Hi Alex
>>
>> Glad to see that this is being productified for Trace Compass. See
>> below for some comments.
>>
>> On 02/15/2016 05:37 PM, Alexandre Montplaisir wrote:
>>> [...]
>>>
>>>
>>> In my current prototype, I just display all available external
>>> analyses under the trace, just like standard analyses are (see
>>> attached screenshot). They can then be invoked by right-click on
>>> them and choosing "Run External Analysis" from the contextual menu.
>>> The results are displayed in non-singleton views, one per table of
>>> output of the analysis.
>> I think it's not ideal to show them on the same level as "standard"
>> analysis. One reason is that they are different (as you already
>> described). Another reason is that the list might get very long.
>> Would it be a valid option to add a separate node under the trace for
>> external analysis and have the list there. By doing that users could
>> select one and right-click on one and run it. The advantage of doing
>> this is that you can provide properties for the properties view that
>> gives some details about the analysis.
>>
>> Alternatively, you could have single entry in the tree under the
>> trace. When user right-click on this element a context sensitive menu
>> could open and the user can select the analysis to run. However, this
>> approach won't give you the possibility to show the details of the
>> analysis in the properties view. You would have an alternative way
>> for the displaying description/details of external analysis.
>
> Thinking a bit more about it, one thing I like about the current
> prototype, and just having the analyses listed under the trace in
> general, is that it helps in discoverability. If it's not immediately
> visible, the user might never find out the option exists.
>
> But as you say, it should be separated from "normal" analyses. I kinda
> like the idea of a separate sub-tree. It could be something like:
>
> mytrace
>
> +- Automatic analyses
>
> | +- Kernel analysis
> | +- CPU Usage analysis
> | +- etc.
> +- On-demand analyses
> +- LTTng-Analyses CPU Top
> +- LTTng-Analyses IO Top
> +- Critical Path analysis (eventually!)
> +- etc.
>
>
> something like that?
Why the eventually next to critical path?
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.
>
> And of course, the Properties view would be a nice place to put extra
> information about each analysis.
Since recently, analysis can provide properties, so it would be a few
liners to just add the help text to those properties for a start.
>
>>
>>> This is not ideal, because it's confusing which analysis are
>>> supposed to be run manually, and which are just there for listing
>>> their outputs. A potential alternative would be to have a new "Run
>>> External Analysis" option, from the context menu of the *trace*,
>>> which would open a dialog to handle all available external analyses.
>>>
>>> Also, we'd probably need a new name instead of "External Analysis".
>>> These may not even be external eventually, they could be defined in
>>> Java, shipped with Trace Compass, and be able to be called on demand
>>> by the user.
>> Good point. External doesn't fit.
>
> Yes, I'm warning up to the idea to "Automatic analysis" vs. "On-demand
> analysis". Other ideas?
>
> Even in the current prototype, the analysis are defined in Java. Since
> there is no auto-discovery yet, each available analysis has to be
> defined manually.
>
>>>
>>> Thoughts?
>>>
>> One thing is needed a way to manage the external analysis (I mean the
>> ones that actually external). I'm thinking of a dialog like the
>> "Manage Custom Parsers" or "Manage XML analyses" where users can
>> import/export/delete/edit external analysis.
>
> Indeed, it would be great to have "Data-driven on-demand analyses" no? :)
>
> But for now, as mentioned above, there needs to be a Java shim for
> each available analysis, with a corresponding extension point entry. I
> would see data-driven-ness as a future step.
Like Bernd said, the future could be here sooner. We can discuss it when
you reach this point, but I think it wouldn't be too hard to add
"data-driven reports" sooner than later. It might even help generalize
what is already available and make everything data-driven!! no Java shim
anywhere (you can have builtin XML analyses come with plugins).
Cheers,
Geneviève
