Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
Hi Dave,

Here's an idea, not entirely sure it will work.

You said that you have your own content provider, let's see if that can help.

In your extended Call Stack view, override getTracesToBuild() so that for each trace (under an experiment if applicable), it returns not one but two instance of ITmfTrace, which would be wrappers of the same trace but that provide a different call stack analysis module.

Then you have two sub-trees in the Call Stack view, with elements that persist and are not rebuilt when you switch analysis. Their respective filters also persist.

Finally you make it so that your content provider completely hides the whole sub-tree of the wrapped trace which corresponds to the not-selected analysis. When switching analysis you just call refresh() and make sure the content provider returns different roots (wrapped traces).

Patrick


On Tue, Aug 2, 2016 at 5:59 PM, David Wootton <dwootton@xxxxxxxxxx> wrote:

Patrick
Yes, the problem is that if I switch between the two analyses, that when I switch back to the first analysis, the filtering settings are gone and all of the threads in the trace are visible again. If I open the TimeGraphFilterDialog, then all of the thread entries are present and checked.

I tried changing my rebuild() calls to refresh() calls. If I make only that change, then my view does not update with the analysis that I wanted to switch to. I still see the results of the same analysis.

The problem might be that rebuild is recreating the CallStackEntry instances as you state. I did see that the fFiltersMap field is updated when a new trace is loaded, with the ITmfTrace object being the map key, and then that map is used to reset the filter when refresh or rebuild are called, so saving and restoring filters across different traces does work.

(The reason I call rebuild has to do with the way I switch between analyses. I specified both analysis to be run automatically when a trace is loaded. Then my class which extends TmfTrace implements an overriding implementation for getAnalysisModules() which determines which analysis is requested and makes sure the corresponding IAnalysisModule is element zero in the list it returns. I did this because there's a private method CallStackView.getCallStackModule(ITmfTrace) which gets the requested analysis module, and is currently implemented so that it returns element 0 of the list.)

Dave

Inactive hide details for Patrick Tasse ---08/02/2016 05:28:37 PM---Hi Dave, I'm not sure I understand correctly, is your problPatrick Tasse ---08/02/2016 05:28:37 PM---Hi Dave, I'm not sure I understand correctly, is your problem that entries that the

From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/02/2016 05:28 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx




Hi Dave,

I'm not sure I understand correctly, is your problem that entries that the user has filtered out with the dialog come back visible when you switch analyses?

I think the problem is that when you switch analyses and call rebuild(), your are creating a whole set of brand new CallStackEntry instances. They do not overload Object's equals(), so they are considered different. Consequently, after calling rebuild() the RawViewerFilter contains obsolete entries that do not match against anything anymore.

Can you avoid calling rebuild() when switching analyses? If you just make sure the content provider hides some entries it should work by just calling refresh()?

Patrick


On Tue, Aug 2, 2016 at 2:10 PM, David Wootton <dwootton@xxxxxxxxxx> wrote:
    I have figured out how to run multiple analyses extended from AbstractCallStackAnalysis for the same trace. I've also figured out how to set a content provider extending TimeGraphContentProvider to my class extending CallStackView so I can make timelines for individual threads visible or not visible like the existing ability to make an entire process visible or not visible using the TimeGraphFilterDialog. I potentially have a lot of threads per process, so this helps the user reduce clutter.

    The problem is that the filtering to hide or show threads does not persist when I switch between analyses for the same thread. If I invoke the TimeGraphFilterDialog to pick a set of threads to hide, the view is updated when I close that dialog.

    I invoke CallStackView.rebuild() when I switch between analyses.

    It seems that this method and CallStackView.refresh() use a private (AbstractTimeGraphView.fFiltersMap) map to track the specified filter active for each trace when multiple traces are open.

    Since I don't seem to have access to this map, I can't update it, so whatever I set using the TimeGraphFilterDialog gets overwritten when I switch analyses.

    If I had a way to update this map via getter and setter methods then I think what I am trying will work. Alternatively, if I had access to the actual RawViewerFilter object then I could update the set of objects filtered in or out. However, that is a private class defined in ShowFiulterDialogAction so I don't see any way to get access to it.

    Is there any way to get access to these objects? Is there another way I could make this work?

    Thanks

    Dave



    _______________________________________________
    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




_______________________________________________
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