Community
Participate
Working Groups
Build Identifier: Within the plugin org.eclipse.papyrus.modelexplorer.widgets, in the Class org.eclipse.papyrus.modelexplorer.widgets.HierarchicViewerFilter, the hasOneVisibleChild(...) function can call itself on the whole content (direct and indirect) of the element passed in parameter (line 94, revision 5147). Doing so, the function can wrongly be called more than once on elements, the number of calls increasing with the depth of the model. Reproducible: Always
There are two problems with the Tree Reference Dialog : - The first one is a performance issue (And potentially, an infinite loop...). The problem comes from the encapsulation of UML Elements in EMF Facet TreeElements (The TreeElements are unique, while the UML Element can be represented more than once ; this prevents the cache from working correctly). This problem is easy to fix. - The second one is really a bug, and is related to the TreeFilters. A TreeFilters displays an element : - If it matches the filter - If one of its children (recursively) matches the filter - Optionally, if one of its parents (recursively) matches the filter This works fine when there is only one filter... Which is almost never the case. When two different filters implement this algorithm, an element becomes visible if : - One of its children matches one of the filters (recursively) - Another one of its children matches the other filter (recursively) This results in elements being displayed, although they don't directly match the filter, and none of their children match all the filters. The whole mecanism of HierarchicContentProvider and TreeFilters should be changed, as this may be really confusing on big models (And this will become even worse when we'll add additional filters). - The "Type" filter should be implemented directly in the ContentProvider, instead of the filter - The filters should only implement the "isVisible" method - The hasOneVisibleChild/hasOneVisibleParent methods should be handled in a single filter, aggregating the concrete ones - There will still be a problem of cache, as we cannot implement an abstract cache (We sometimes need to resolve the "semantic" element) - We may also investigate on a different way of displaying filtered elements, based on the "IDetailLabelProvider" : we display a flat list of elements when the filters are activated, and we use the IDetailLabelProvider to display their qualified names (It can be really boring to browse the whole tree to find the matching element...). This mecanism is similar to how Windows displays the search results (Flat list with qualified names) I will soon commit the first fix on the branch, but the other one will have to wait for the next version of Papyrus, as it involves major changes.
