Community
Participate
Working Groups
Created attachment 115983 [details] Class 1 of 2 I have several RCP apps with a UI design in the spirit of bug #11001 comment 36. I tweaked the default WorkbenchPresentationFactory to provide some of the functionality of the normal editor presentation to views. Specifically, the close box is displayed on all view tabs (not just the one on the top of a stack), and the "Close", "Close Others", and "Close All" options are available on the context menu for view tabs. I need some guidance about where this code should belong, and if it should be restructured somewhat to make better API. In particular, I had to implement an internal interface (ISystemMenu) to change the behavior of the default presentation. If this code goes anywhere but Platform UI, this interface would need to be promoted to public API.
Created attachment 115984 [details] Class 2 of 2
One option for the first part of your change would be to allow folders to set one or 2 API properties while creating the perspective using org.eclipse.ui.IPlaceholderFolderLayout.setProperty(String, String). Then the perspective gets to decide. Then it would be a minor enhancement to updated org.eclipse.ui.presentations.WorkbenchPresentationFactory to use org.eclipse.ui.presentations.IStackPresentationSite.getProperty(String) to set those booleans, maybe org.eclipse.ui.folder.unselectedCloseVisible and org.eclipse.ui.folder.unselectedImageVisible. The menu is a little harder. One enhancement here for removing menus could be to include them in activities, using folder.<folder.id>/<action.id>. That way an RCP app could remove select system menus from view or editor stacks with a few activity pattern bindings. This doesn't help with the "adding menu items" part though. Actually allowing menu items to be added generically is a feature including API (adding them using commands and handlers, making the appropriate information available at the correct time, etc). Adding another view folder presentation property to include the Editor items (except for New Editor) would be relatively easy, but we would need to work through the usecases to make sure this would satify the users. PW
Oh, and thanx for the suggestion and contribution offer. That really helps us understand what might work. PW
Created attachment 116376 [details] Presentation can determine view image/close behaviour Here's an example of using the folder properties to set the unselected close behaviour on view stacks. Example use in a perspective factory: IFolderLayout left = layout.createFolder("left", IPageLayout.LEFT, .3f, layout.getEditorArea()); left.addView(IPageLayout.ID_OUTLINE); left.addView(IPageLayout.ID_PROP_SHEET); left.setProperty(WorkbenchPresentationFactory.UNSELECTED_CLOSE_VISIBLE, "true"); left.setProperty(WorkbenchPresentationFactory.UNSELECTED_IMAGE_VISIBLE, "false"); PW
I'm unsure if I like where this is headed. In my case, I want all of the views in my app to act the same, so my initial reaction is that these should be set globally in the presentation, not per view stack. I can see how someone might still maintain the distinction between views and editors from a user's perspective, but use IViewPart to implement both under the hood. This approach (setting properties per view stack) would handle this case. However, there are still problems. What happens if a user drags a view from one stack to another? In the end, I would choose to stay with my current implementation rather than switch to the new API you propose. I don't want to change all of my perspective layout code to set these properties and risk inconsistency if I miss something. As you say, this is the easy part. The behavior of the menus is much more complex. Honestly, I doubt that it is worth the time to sort out an API. I was merely hoping that this particular policy would be available for other RCP developers, not to add an API for fully configurable policies. Adding these classes is not complex in itself, assuming that they become part of platform.ui. In that case, extending code that is internal to the same bundle is not a problem.
The PresentationAPI has been deprecated with the Eclipse 4.x release and it has been replaced with the CSS engine. I therefore close this bugs as WONTFIX. In case your bug report is still valid for the Eclipse 4.4 release, please open a new bug report for it.
