RE: [mylar-dev] Working Set and its Context

["Mik Kersten" <beatmik@xxxxxxx>]

Thanks for the clear description of an important use case Ivica.  I'm also
curious how often people are falling back to unfaltering the views.  The
short answer to your question is that you can also use Alt+click to unfilter
nodes in any filtered view

The long answer is that the context for any task is what you've been working
with in the past (e.g. stuff that shows up in the Package Explorer) and
everything else you'll need to look at or edit in the future in order to get
the task done.  Part of the reason the current filtering works well is that
much of what we need to look at in the future is what we've already worked
with in the past.  But there are a few key cases that Mylar needs to make
easy in order to put the additional information at your finger tips:

1) ELEMENTS RELATED BY THE CONTAINMENT HIERARCHY

This is the primary case you describe.  Since as you indicate it is way too
annoying to toggle the Mylar filter every time you want to browse for a
file, class, or member that's related we let you Alt+click any node in the
package explorer in order to temporarily surface all of it's children.  With
Mylar 0.5.0 if you Alt+click in the whitespace of the view all root nodes
(e.g. projects) will get unfiltered.  Regarding showing how many things are
unfiltered, we had that working in Mylar 0.2 (see the AOSD paper), but it
turned out to be visual noise because when the filter is on you can simply
assume you're not seeing everything, and Alt+clicking is easy. 

2) ELEMENTS RELATED TO THE LOCAL CONTEXT

Often the things we need to browser to are not in close 'proximity' in the
containment hierarchy, e.g. a method calling the method we're working on.
Eclipse does a great job for that in the local file (e.g. mark occurrences
and Ctrl+Shift+U).  What we have on the table is an in-place view that will
show you structurally related elements for your current selection.  Think of
it as an Active Search version of Ctrl+O.  If you have any specific use
cases please comment on:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=104052

3) STRUCTURALLY RELATED ELEMENTS

As you work you build up a context that's not visible in the Package
Explorer because it contains elements that are connected by arbitrary
relationships (e.g. XML references to Java elements, inheritance).  Eclipse
let's you get to these via search, but that involves a lot of manual
inspection of results and repeated search invocation.  Addressing that has
been the job of the Active Search view, which provides all the functionality
needed to for this but has the following notable failures:
- Only shows you the context of landmarks, which will hopefully be addressed
by (2)
- Shows way too much when you have rich context if you don't manually tune
the degree-of-separation, which could be addressed by adapting your
degree-of-separation scope as you work

Eugene and others have pointed out many additional related problems with
Active Search (see bug reports with "active search" in them), and getting
that UI right will be a focus for 0.6 as well.

Mik 

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Ivica Aracic
> Sent: Tuesday, April 04, 2006 5:47 AM
> To: Mylar developer discussions
> Subject: [mylar-dev] Working Set and its Context
> 
> 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
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev