Community
Participate
Working Groups
I20030716 + ZRH M2 plugin export - open JavaDoc view and Declaration view - open Java CU with many members in Editor - in Outline select first member - with the cursor down key step through all members Observe: both the JavaDoc as well as the Declaration update with every selection change (and are hardly able to keep up). The editor only updates after some timeout. I think the JavaDoc and the declaration view should use the same strategy.
Looks like a platform bug since the info views listen to post selection changes. Needs investigation.
The page book view does not respect IPostSelectionProvider.
Daniel, what do you mean "does not respect IPostSelectionProvider"?
There is a new IPostSelectionProvider interface which is implemented by structured viewers, text viewers and Java outline page. Parts that act as selection provider for other parts (like page book for Java outline page) should implement that interface. PageBook and MultiPage editors are such parts. If they don't then the benfit of implementing IPostSelectionProvider gets lost for children/clients of such grouping parts.
This is still an issue in 3.1. PageBookView's selection provider should implement IPostSelectionProvider. If the active page supports IPostSelectionProvider, then its selection and postSelection events will get mapped directly. If not, then PageBookView should fire both a selection and postSelection event for a selection event from the page.
I'm going to have to defer this one to 3.2.
I think the PageBookView can follow the same pattern as the MultiPageEditorPart, and have it's SelectionProvider be an IPostSelectionProvider. I'll have a trial patch soon. PW
The PageBookView SelectionProvider now implements IPostSelectionProvider. Where before a selection change would notify an selection change listeners, it now also notifies any registered post selection change listeners. Please comment on this update. Released into HEAD >20060131. PW
The superclass of JavadocView, AbstractInfoView, already hook themselves as post selection listeners on the part service (it should listen on the page's part service, not the window's). So with your change, we should be able to see a direct performance improvement, as long as PageBookView's SelectionProvider actually fires post selection events in response to the viewer's post selection event.
>it should listen on the page's part service, not the window's. Why? Isn't the current code more general and also handles the case where a window has more than one page (I know I know the current IDE layout doesn't do so but still)?
For things that are within a page, such as parts or actions within them, they should look up only to the page's part service (and selection service) because parts are not shared between pages. For example, it wouldn't make sense for a Javadoc view in page 1 to show info for code selected in an editor in page 2 because the two will never be shown together. For parts that live at window level outside the page, such as action set actions, they should use the window services. But admittedly this is a bit of a fine point, since there's only 0 or 1 pages in the current implementation.
Changed AbstractInfoView. Fixed in HEAD.
fixed
verified in RC5 PW
