Community
Participate
Working Groups
N20060611-0010 The platform should define a command for cycling through pages of a PageBookView (e.g. Search, Console, Synchronize) or other views that use a notion of switchable pages (e.g. JUnit, Type Hierarchy, Call Hierarchy). There should be a retargetable action that can be used by views that want to support easy switching between their pages. The action cannot be bound by default, since some PageBookViews may not want to give the user this power (e.g. Outline), or they need to know about page switching events (e.g. JUnit). Good default keybindings would be Alt+PageUp / Alt+PageDown. Today, using such views is often cumbersome, since the views usually only offer a dropdown toolbar button, which has a very small target area to open a menu. Furthermore, opening the menu is unnecessary when the user already knows she wants to go to the previous/next page.
Could this bug please be considered for 3.4?
Created attachment 80703 [details] basic functionality of cycling pages So far it works for at least the Console view. It won't always show the cycle list with a predictable order since PageBookView stores pages in a Map. The Search view so far won't work without some further investigation. It doesn't seem to store all of its pages in the PageBookView's Map. TypeHierarchyViewer will require more investigation since it's not a PageBookView. Another handler based on CycleBaseHandler should do the trick. Performance is ridiculously slow. Still determining the cause.
Comment on attachment 80703 [details] basic functionality of cycling pages This proposal does not fulfill (and is not extensible to fulfill) the requirements from comment 0: - The mechanism should be completely independent of the view implementation. PageBookView is just one way to implement views with multiple pages. - Views should opt-in to get this support. The hack to exclude the Outline view show that including this in PageBookView is not the right approach. Predefined adapters for e.g. a PageBookView could still be worthwile. Furthermore, I'm not sure if you can add a method to IPageBookViewPage. Its Javadoc says * Pages should implement this interface. but Page and IPage say that clients should subclass Page.
Created attachment 80790 [details] cycling pages v02 Rework of the patch: 1) we missed the "must extend Page" on IPageBookViewPage, so we're stuck with IPageBookViewPage2 2) it is now opt-in. registerPageSwitchingHandlers() in the createPartControl(*) will active the commands for that view. The changes to org.eclipse.ui.console show an opt-in example Any view can contribute handlers to the org.eclipse.ui.navigate.nextPage and previousPage commands. If you are already using PageBookView, you can get opt-in relatively easily. Open issues: 1) anyone can opt in, but they will only get their behaviour without the Cycle handler support as that's all internal classes ... we can either look at some API around the cycle behaviour or "switch" to a simple "go to the next rec" version 2) if we continue using the cycle behaviour, we'll need to enhance it to select the next rec in the list (ours is currently unsorted). Just starting at the top doesn't work in this case. 3) do we leave the keybindings in the window context, or move them to a "page switching" context that any switching view would have to activate (the way we are currently activating our handlers). PW
(In reply to comment #4) > > Any view can contribute handlers to the org.eclipse.ui.navigate.nextPage and > previousPage commands. If you are already using PageBookView, you can get > opt-in relatively easily. > > Open issues: > > 1) anyone can opt in, but they will only get their behaviour without the Cycle > handler support as that's all internal classes ... we can either look at some > API around the cycle behaviour or "switch" to a simple "go to the next rec" > version > > 2) if we continue using the cycle behaviour, we'll need to enhance it to select > the next rec in the list (ours is currently unsorted). Just starting at the > top doesn't work in this case. > Markus, we can either leave the fact that these are commands to allow any multi-page view to opt-in and just provide a specific implementation for PageBookView, or we can provide a handler and a public interface that a view could implement to be used with the cycle handler, something like: ICyclePage { public IPageBookViewPage2 getPages(); public IPageBookViewPage2 getSelection(); public void setPage(IPageBookViewPage2); } Do you have a preference? PW
I still don't think this should be tied to PageBookView in any way. The management of pages in a page book is entirely up to the subclass, and I don't think it's a good idea to add something like IPageBookViewPage2 and a "default" handler in PageBookView. The console view example already shows how this approach fails: - icons for pages are wrong - order in the chooser is wrong - TextConsolePage needs to implement IPageBookViewPage2 and delegate getLabel() to the IConsole. It would be bad if all IPageBookViewPages would have to do this, although the managing view already knows how to render page descriptions (e.g. in the history menu). It's even worse for contributable pages, e.g. ISearchResultPage. I would take this out into a separate manager class, e.g. something like: public abstract class PageSwitcher { public PageSwitcher(IWorkbenchPart part) { /* register handlers */ } // callbacks to be implemented by clients: public abstract Object[] getPages(); public abstract String getName(Object page); public abstract ImageDescriptor getImageDescriptor(Object page); public abstract void activatePage(Object page); } This would clearly separate the page switching code from the internal implementation of the view and the pages, and it would also allow e.g. MultiPageEditorPart or the type hierarchy to offer the page switcher. Furthermore, it would be nice if the page switcher popup could be centered in the originating workbench part. The current location (center of the window) can be far away from the active part. NPEs I got with v02: a) When the Console view is empty: java.lang.NullPointerException at org.eclipse.ui.internal.console.ConsoleView.showPageRec(ConsoleView.java:144) at org.eclipse.ui.part.PageBookView$CyclePageBookViewHandler.activate(PageBookView.java:203) b) When you press and hold Alt+PageDown, release PageDown, and then click into the Console view while the chooser is still up: java.lang.NullPointerException at org.eclipse.ui.internal.console.ConsoleView.showPageRec(ConsoleView.java:136) at org.eclipse.ui.part.PageBookView$CyclePageBookViewHandler.activate(PageBookView.java:203)
(In reply to comment #6) > I would take this out into a separate manager class, e.g. something like: > > public abstract class PageSwitcher { > public PageSwitcher(IWorkbenchPart part) { /* register handlers */ } > // callbacks to be implemented by clients: > public abstract Object[] getPages(); > public abstract String getName(Object page); > public abstract ImageDescriptor getImageDescriptor(Object page); > public abstract void activatePage(Object page); > } > > > Furthermore, it would be nice if the page switcher popup could be centered in > the originating workbench part. The current location (center of the window) can > be far away from the active part. > OK, Tim, could you try and whip up a patch based on this pattern. Put the PageSwitcher class in org.eclipse.ui.part for now. PW
Created attachment 81304 [details] cycling pages v03 This uses a separate class to provide behavior that CyclePageHandler can use to cycle pages. The Console view has been changed to implement page cycling. - The dialog still has to be changed to display in the center of the view. - Icons are correctly shown for the console pages. - The cycle order is shown by MRU. It should be easier now to opt-in page cycling behavior. The view will have to implement IPageManager so that the handler can get an instance of IPageSwitcher, which provides the access to switching pages.
Created attachment 81450 [details] cycling pages v04 Added dialog centering on view. Centers on primary monitor if the dialog is out of monitor bounds when centering on view.
Have a go at the patch with the following modifications: Get rid of IPage* and just create an abstract class PageSwitcher. Implement the constructor to activate your handler against the part site IHandlerService. Pass in the page switcher to your handler. Remove the handler activations from the plugin.xml In your Console view example just instantiate the PageSwitcher as an inner class. Just extract the co-ordinate code from the openDialog and override that in CyclePartHandler. Later, PW
Created attachment 81463 [details] cycling pages v05 Modified with changes stated in comment 10.
Created attachment 83339 [details] cycling pages v06 Some minor modifications. Please check the CycleBaseHandler for potential changes to center the dialog. PW
Created attachment 83877 [details] cycling pages v07 + Fixed the centering of the dialog on the view. + Added truncation to the dialog item so the dialog is more likely to be within the bounds of the view.
(In reply to comment #13) > Created an attachment (id=83877) [details] > cycling pages v07 This is almost there, you just have an image leak in CyclePageHandler in addItems(*): item.setImage(imageDescriptor.createImage()); One of the ways we do this is to create a LocalResourceManager like: LocalResourceManager m = new LocalResourceManager(JFaceResources.getResources()); Use that to create the images, and then once the dialog is disposed you can dispose the local manager and null it out. Then I think this is ready to go. PW
Created attachment 83898 [details] cycling pages v08 + CyclePageHandler disposes of the LocalResourceManager, if it was created.
Released into HEAD >20071130 The commands and new API, but not the keybindings. PW
Verified I20071211-0010
