[mylar-dev] Working Set and its Context

[Ivica Aracic <aracic@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Using Mylar recently I've made the observation that Mylar really speeds 
up my work by removing irrelevant elements from the view. However, I 
have also experienced situations where I was forced to disable Mylar 
views first, browse for the desired class in the unfiltered Package 
Explorer and then reactivate Mylar views again.

The concrete case was: I wanted to add a new AST-Node in a complex 
AST-Hierarchy. As I was not sure how the interface methods should be 
implemented, I wanted to check already existing implementations of 
similar AST-Nodes. Since I had no specific AST-Node in my mind I wanted 
to browse in the package for it. However, this forced me to deactivate 
Mylar's filter. But this had the consequence that not only the elements 
from the same package were shown but also all other elements in the 
project, which lead to the information flood again.

This lead me to the question: could the efficiency of the developer be 
improved if Mylar would offer more context information for the current 
working set the developer is working with?
With context I mean in this case the surrounding of the working set 
which has been filtered away.

The simplest case would be to extend Mylar views with additional 
elements being representativ for the elements removed by Mylar, e.g.: 
"... 34 more classes"- or "... 10 more packages"-nodes, which can be 
expanded, maybe opening a kind of preview, allowing the developer to 
select desired elements and collapse the rest easiely. This would avoid 
disabling Mylar filter, browsing for the desired element, and 
reactivating the Mylar filter again.

The second question is: how often such forced fallbacks to unfiltered 
views occure?
Did anyone else experience similar situations?


Ivica