Community
Participate
Working Groups
In an RCP application I want to be able to prevent views from being hidden (closed). Also I'd like an option to lock them in place in order to prevent them from being moved and/or resized. There is an internal Perspective.canCloseView() method but the API is not exposed anywhere I can find. Use case: user interfaces designed for unsophisticated workers (like data entry) need to be very simple. If a secretary closes a view and doesn't know how to get it back, or makes it really small by accident, that's an extra call to the help desk.
See also bug 41152.
We are planning on adding the following support to support fixed views and perspectives. - introduce the notion of a fixed view, which means that it is not closeable or draggable - introduce the notion of a fixed perspective, which means that the initial overall perspective layout cannot be changed: no layout folders can be created or removed through DnD, and no DnD allowed between folders (DnD of non-fixed views would still be allowed in the same folder) The new APIs to support this will be: - IPageLayout.addFixedView(...) // same args as current addView - new optional attribute on the <perspective> element in the perspectives extension point: fixed=<boolean> (defaults to false) - new optional attribute on the <view> element in the perspectiveExtensions extension point: fixed=<boolean> (defaults to false) - this is the XML equivalent of IPageLayout.addFixedView In addition, to give the perspective more control over where new views appear, we will allow an "unknown view" placeholder to be created in -one- of the perspective's folders (augmenting the current mechanism which allows the creation of placeholders for specific views). The API for this will be: - IPlaceholderFolderLayout.addUnknownViewPlaceholder() (note that IFolderLayout also inherits this method)
Sounds good. Will the fixed view have a different appearance? Will there be a way to convert a fixed view to non-fixed and vice versa?
A fixed view will have the same appearance, except that it will not have a close button. Likewise, it will not have Close, Move or Fast View on its system menu. We're still debating whether it makes sense to allow fixed views to be zoomed, but it probably doesn't. So double-click to zoom would go away, as would Maximize and Restore on its system menu.
We were not planning on allowing the fixed state to change after creation (either for the view or the perspective).
> - new optional attribute on the <view> element in the perspectiveExtensions > extension point: fixed=<boolean> (defaults to false) > - this is the XML equivalent of IPageLayout.addFixedView Will this attribute be honored only when extending a "fixed" perspective? If this is the case then I think its okay. Otherwise you shouldn't be able to extend an existing perspective with a fixed part. I'm wondering if addFixedView and createFixedFolder would be enough to satisfy the requirement. When a perspective is "fixed" is there any difference between addView and addFixedView? I propose that both cases are supported. A) When a perspective is fixed via fixed=true in the extension spec, all parts created in the initial layout are fixed. B) A perspective is not fixed. Fixed views may be added via addFixedView() and fixed folders are added via createFixedFolder. Fixed parts may only be added by the perspective factory. The perspective factory may always define an "unknown view" placeholder. Option A is less flexible. All parts created by the perspective factory are fixed. Option B is more flexible. It allows the perspective factory to mix fixed parts with parts that are not fixed.
Good plan. One tweak to suggest. Allow the declaration of fixed or not for both view and persepctive to be specified programatically. I.e the advisor can declare a perspective to be fixed or not (there might be two modes that an app runs in) Same for views. How does the tie in with the dynamic / multiple instance of views work item?
If we allow whether a perspective is fixed to be changed at runtime, then that impacts on the API questions Matt poses above. Matt and others, if your apps were to allow the user to toggle whether layout is fixed or not, how would you expect it to work? Is this something that you would toggle at the perspective level or at the individual view level? API-wise, this toggle would probably manifest itself as get/setFixed(boolean) on IWorkbenchPage, and would apply to that page's active perspective only.
I have some questions for Paul. Are you suggesting being able to modify the fixed state at runtime, or simply being able to determine at launch time whether a perspective is fixed or not. If so, the proposed API for views and folders should suffice. On the other hand if you want the ability to toggle the fixed state of a perspective without restarting the Workbench we may be complicating the story and will need to introduce additional API. Currently, I do not have a use case for toggling the perspective's fixed state at runtime. I would imagine that an application defines a perspective as either always fixed or not. Toggling at the view/part level seems to make more sense, but this needs to be mediated by the advisor or the perspective factory.
In my opinion there should be two combinable options: 1. view cannot be closed ("non-close view") 2. view cannot be moved/resized ("fixed view") Why should we take away the user's ability to rearrange his UI just because we don't want him to be able to close the last (or main) view of a perspective and thereby closing the whole perspective? The only thing bothering me right now is that the concept of "perspectives" is forced onto the user even if there is only one perspective behind the scenes.
Hi, I vote for: 1.Fixed views(no close, resize, move) 2.Hide the views toppanel(where the name and the menu are). I don´t need it
> I vote for: > 1.Fixed views(no close, resize, move) > 2.Hide the views toppanel(where the name and the menu are). I don?t need it Only optional. I agree that in some cases title part of view is not needed, but in other cases we need it to show view title and be able to maximize it. Maximization is second thing that I ask to make optional, I see that there was decision to remove it for fixed view. Please don't do this. Allow us to configure as much as possible, especially when we create views in perspective factory.
views should not only be configurable to be fixed or not. all of the following attributes sould be modifiable independently from each other: close resize move maximize In my opinion, particularly the combination of close=false and maximize=true is useful and reasonable.
GEF clients need a way to display and fix the Palette Viewer when their editors are opened. Besides lockick the view, we also want the view to go away when it is not in use by the active editor.
I would like to propose the modifications to support this feature request. The actual modifications will be attached to this bugzilla along with a test case plug-in. I tried to blend in most of the additional suggestions above and came to the following rules. 1) Fixed views can be added with "addFixedView". Fixed views can be moved, but cannot be closed. Fixed views may only be moved when the active perspective is not fixed. The fixed state of all views will persist. 2) Fixed perspectives or layouts can be created with the "fixed=true" attribute or "PageLayout.setFixed(true)" in the PerspectiveFactory. No parts in a fixed perspective can be moved at any time during the life of the perspective. All initially created views in a fixed perspective are created as fixed, thus they cannot be closed. All views added to a fixed perspective either through a perspectiveExtension or page.showView are not fixed, thus they can be closed. The fixed state of the perspective and all views will persist. I did not implement any toggle functions. I'm thinking the toggle feature can be handled by the PerspectiveFactory if and when "restorePerspective" becomes public API. Applications can listen for a preference change and restore the perspective with the updated fixed state with layout.setFixed(state). Of course this only supports toggle at the perspective level. I don't think toggling fixed state at the view level is important at this time. I did not implement the "unknown view" place holder yet. I'm thinking the unknown place holder is always be a folder since multiple unknowns are almost always expected. Anyone disagree?
Created attachment 7613 [details] modifications to support this feature request This zip contains the modified files based off of HEAD along with diffs in a few formats and a patch.
Created attachment 7614 [details] test case for the proposed modifications attachment this zip contains a test case plug-in for the proposed modifications.
I looked over the code in the patch. I assume all the theme stuff is for some other change so I'll ignore it for now. It's a little confusing in some areas because the meaning of "fixed" is unclear. In some places it seems to mean "!closable" and in some places "! movable (== !draggable)" and in some places "!zoomable" and in some places "! resizable". Having methods like isClosable() adds to the confusion. I was also confused a bit about the difference between the fixed flag on PageLayout, the one on Perspective and the one on ViewPane. In PartTabFolder you have: if (tab == null || page.isFixedLayout() || !pane.isMoveable()) Testing both the page and pane here doesn't feel right to me, shouldn't those concerns be kept separated? I'm not sure passing page to PartTabFolder is a good idea for this reason. Are you envisioning that a view might be closable in one perspective but not in another perspective? Of course it makes sense that a view might be open and unclosable in one perspective but not even open in another perspective, so maybe that's what you're trying to get at. How about editors? If you put the flags on PartPane or WorkbenchPart, wouldn't that be a better place, so views and editors could both be marked as unclosable?
> I looked over the code in the patch. I assume all the theme stuff is for some other change so I'll ignore it for now. Yes you can ignore that. I had some sync issues with CVS. > It's a little confusing in some areas because the meaning of "fixed" is unclear. I agree it may be confusing, however these are internal details. The public API and rules are clear. A) Fixed View = not closeable B) Fixed Perspective = initial parts are not closeable and no parts are moveable or zoomable. > ...if (tab == null || page.isFixedLayout() || !pane.isMoveable())... > Testing both the page and pane here doesn't feel right to me, shouldn't those concerns be kept separated? Unclear right now. I believe I noted this as an issue in the code. Since both tests reflect the same thing (the perspective's fixed state) only one test is needed here. Logically though I think it makes sense to test for both, as the tests might not reflect the same thing in the future, ie. you may have a layout that is not fixed with a view that is not moveable. I know, that is not possible with the proposed mods. Having just one test would work for now. > I'm not sure passing page to PartTabFolder is a good idea for this reason. Other subclasses of LayoutPart have references to the page so I think it's reasonable. Up until now PartTabFolder just didn't need it. Can you be more specific? > Are you envisioning that a view might be closable in one perspective but not in another perspective? Absolutely. View instances are shared across perspectives. A View alone cannot maintain it's fixed state, it must always query the active perspective. > How about editors? If you put the flags on PartPane or WorkbenchPart, wouldn't that be a better place, so views and editors could both be marked as unclosable? If you have a use case for editors not being closeable please specify it. I cannot imagine one.
I would recommend a single integer property which represents the user's rights/privileges. This integer would be either an enum of constants or a bitwise OR-ing of allowed actions. Also, the rights of a view could not exceed the global rights allowed by the perpective. Using an integer allows the addition of new capabilities in the future without new API.
Use case for editors is the same as for views: for RCP applications, making the user interface simpler for unsophisticated workers by preventing them from accidentally closing something the application designer didn't want closed. I should have mentioned editors in my original request but didn't because I haven't used an editor yet in my RCP apps. Regarding the API, if you used the term 'fixed' only for perspectives (meaning: parts it contains are not moveable or zoomable or resizable) and used 'closable' or 'unclosable' for views/editors (meaning: part cannot be closed) then I think that would make it a little more clear without the reader consulting the API rules.
Matt, I'm in the process of merging the changes in. The example seems to be missing the plugin.xml and image files though.
Created attachment 7658 [details] zip containing a test case for the proposed mods Replacement for previous test case attachment that was missing some files.
I've released the changes to HEAD. Still TBD: - need to update closeability/moveability when switching between perspectives - address concerns above about semantics of fixed vs. moveable/closeable/zoomable
Created attachment 7661 [details] updated test case with source and new icons Sorry, previous attachment did not have source. I've updated the test case with the source and some new icons.
In M7 the javadoc for IPageLayout.addFixedView() says: * Once added, a fixed view cannot be moved or closed. This is different from comment #19, which says a fixed view simply cannot be closed. From playing around with M7, I think the javadoc is wrong. Eclipse lets me drag fixed views unless they're part of a fixed perspective.
Fixed up the Javadoc for IPageLayout.addFixedView().
This support was broken by the new look merge and needs to be fixed for M8.
i looked at this today. fixing the breakage requires a few changes to some internal classes under significant restructuring to abstract the presentations of views and editors. (stefan has asked we don't touch these classes for a couple of days.) i spoke with him today about fixed view support in the presentation interfaces, and we have altered them to include support for immovable and uncloseable views. ideally, we would like to fix this bug as part of the restructuring. i expect this bug will be fixed for the end of the week, and certainly for the next integration build. if an earlier build is necessary please advise.
The current APIs only allow you to specify fixed on the perspective as a whole, or on an initially-visible view, but not on a placeholder, so it's not possible to say "this view is not showing initially, but when it does it should not be closeable/moveable". Seems like there should be a fixed variant of IPageLayout/IPlaceHolderFolderLayout.addPlaceholder.
Created attachment 8566 [details] patch to support fixed place holders This is a patch to fulfill Nick's request at comment #30. -m@
Patch released with the following changes: - added IPageLayout.addFixedPlaceholder(...) - added @since 3.0 tags to new API methods - changed PlaceHolderFolderLayout.addPlaceholder to add to fixed list if page layout is fixed (same as is done for non-placeholder views) - added PageLayout.markAsFixedView(String viewId) to hide the representation, and changed add* methods to call it as appropriate
is it possible to add a fixed view with the org.eclipse.ui.perspectiveExtensions point?
Not currently, but that is planned for M9.
This is in good shape for M8 except for bug 55927. Need to revisit the API in M9.
*** This bug has been marked as a duplicate of 60704 ***
Sorry, wrong PR. This is not a dup of 60704.
Added more explicit API for configuring whether a view is moveable or closeable. See IPageLayout.getViewLayout(String id) and IViewLayout.setMoveable/setCloseable. TBD: add similar support to the perspectiveExtensions extension point.
The fixed attribute on perspectives will remain. This means: not moveable and not closeable for all initial views and folders in the perspective. Will remove addFixedView and addFixedPlaceholder methods from IPageLayout and friends (the IViewLayout methods work for placeholders as well).
Removed addFixedView and addFixedPlaceholder methods. Added attributes to perspectiveExtensions extension point: closeable, moveable, standalone, showTitle. The API changes are now done for 3.0. Known issues: - standalone views can still be dragged, and dragged onto - "unibrow" mode doesn't handle toolbar well - if view not moveable, can still be moved (once) - if view not moveable, can still move whole group into another folder, even if only one in group
In RC1, if a view is in a fixed perspective, it is not maximizeable. Maximize appears enabled on the view tab's context menu, but it has no effect. I've filed bug 64836 to track this for RC2.
I am using fixed views in M8 and RC1. In plugin.xml my perspective is declared as fixed and in the createInitialLayout() method of my perspective class the placeholders for all views are set non-closeable and non-moveable. I open the views in code some time later with "workbenchPage.showView(viewID)". Opening the perspective for the first time anything is working fine. When I close the workbench and reopen it again, all views being opened before are closeable and moveable now. If I close and reopen the perspective anything is fine again. Is this the desired behavior? Perhaps its a bug.
Dirk, this works OK for me on RC1, and I believe it worked OK in M8 as well (we had some problems with fixed view persistence before that). I augmented the browser example with a history view, with a placeholder added for it in the perspective factory, and configured the workbench to save state between sessions. I then show the view, shutdown, restart, and both the history view and the browser view come back fixed. Could you please open another bug report providing more details, ideally with a sample plugin attached showing the problem. Please cc me on it.
Not sure why this is still open. It was fully addressed for 3.0. Closing.
