Community
Participate
Working Groups
AJDT's FFDC aspect (and sub-aspects) have advice with many, many outgoing relationships. Clicking on the gutter marker and the "advises" sub-menu will open a context menu that is essentially unusable with hundreds of entries. There is a huge potential for improvement in this area and it may have a big impact on some very common kinds of infrastructure aspects. A suggested improvement is this: If there are more than a certain number of outgoing relationships of a certain type (say 10, but this should be configurable), instead of showing a sub-menu, it would say something like: Advises (305 locations)... Clicking on this will open up something that looks like an Open Type dialog, but is populated by all the advised locations. There is a filter box on top that behaves similarly to the open type dialog's filter. An alternative would be to use something more like an in-place outline view or a content assist box. Giving focus to any item would bring up an info box that shows the code snippet that is advised (similar to how the content assist info box works now). See also bug 79723 for a similar discussion on improving the UI for crosscutting navigation through gutter markers.
Another possibility that I think we have discussed before: If there are 4000 advised places (for example), introduce higher level context menus that make navigation easier. I imagine for that kind of prolific application of advice you wouldn't be thinking in terms of each individual location *anyway*, you'd be more likely thinking 'have I covered everything I think I should have?'. So introduce a type level above the individual advice level Advises->Foo->line 4 line 5 line 6 Bar->line 4 line 5 line 6 (Foo and Bar are also clickable so I can jump to them, at which point the xrefs view will be showing all the incoming advice to the type). Too many types in the menu? Switch up to the package level Advises->com.foo.goo->Foo->line 4 line 5 line 6 Bar->line 4 line 5 line 6 com.foo.boo->Foo->line 4 line 5 line 6 If I were advising 4000 places, it would be nice to quickly tell 'yes I appear to have blanket coverage of that package with this aspect', which you could do with this scheme. A filterable open type dialog for searching as to whether you've advised the right places is also interesting, but we'd have to be careful that the user doesn't loose the context of their activity when they open it - it'll need lots of text on it saying what the big long list are the relationships for. Column for sorting/searching on advised type/package will also enable a similar behaviour to that I described above with the dynamic context menus. > An alternative would be to use something more like an in-place outline view or > a content assist box. Giving focus to any item would bring up an info box > that shows the code snippet that is advised (similar to how the content > assist info box works now). I don't know that I like the sound of this, maybe I need to see some mockups.
Move to the 2.0.2 release.
Try to solve for 2.1.0.
Determining what will be tackled for 2.1.1 release.
Attempted cheat by replacing submenu with a org.eclipse.ui.dialogs.FilteredTree (wrapped in a SWT Shell). Was able to control display of the FilteredTree with IMenuListener2 on the MenuManager. But this approach ultimately won't work because you can't get the bounds of a SWT Menu to position the FilteredTree to where the submenu should be.
