Community
Participate
Working Groups
The WorkbenchAdvisor should be accessible from Plugins to catch the workbench's lifecycle events. In an RCP application a plugin should be asked if the platform may shutdown on File-Quit (e.g. a view might have unsaved data (sometimes an editor cannot be used as long as there is no way from stopping an editor from being closed by the user)). Right now in WorkbenchAdvisor.preShutdown() I ask the views to prompt the user if the platform may shutdown. IPartListener cannot stop the platform from shutting down. The views I find in my WorkbenchAdvisor via configurer.getWindow().getActivePage().findView(IDVIEW). This works, but results in a dependency of RCPWorkbenchAdvisor to the views. So I thought of having the views register themselves in RCPWorkbenchAdvisor. But there is no way to access the WorkbenchAdvisor from a plugin. There should be a method, e.g. IWorkbench.getAdvisor(). Right now there is Workbench.getAdvisor() but it is package private.
It is intentional that regular plug-ins cannot access the WorkbenchAdvisor. The WorkbenchAdvisor gives special powers to the application that regular plugins should not have. It would be better to address the limitation you point out by providing new workbench lifecycle events to regular plugins, including a pre-shutdown notification, and giving the ability of any of the interested plugins to veto the shutdown.
Yes, you are right, providing the workbench lifecycle events to regular plugins would suffice and would be better.
We could provide API on IWorkbench, e.g. IWorkbench.add/removeWorkbenchListener(IWorkbenchListener) where IWorkbenchListener has something like: interface IWorkbenchListener { void postStartup(); boolean preShutdown(); ... } However, the plugin would have to already be activated in order to hook the listener. It may be better to provide this as an extension point, allowing the extension to specify which events it's interested in, so that we don't have this bootstrap problem. Which would be better for your scenario?
Un un-activated plugin would not have dirty data, so the need for a plugin to be activated to register itself seems not to be a problem to me. Anyway, in an RCP app the product plugin is activated on startup. I'd prefer a IWorkbenchListener, its idea is consistent to IPartListener. Also, I don't like XML descriptions, it is too easy to make mistakes -> Bug 70198.
(In reply to comment #3) A listener-method in IWorkbenchListener(2) would be good. Can you implement this in 3.2, please.
*** Bug 79986 has been marked as a duplicate of this bug. ***
*** Bug 113955 has been marked as a duplicate of this bug. ***
With the current support in 3.1, views can implement ISaveablePart, and fire the appropriate dirty state change notifications. The user would be prompted to save any changes on shutdown if the view reported that it was dirty, even if all editors were closed. See also bug 112225.
It would still be nice to have this ability from the plug-in. In our case the file (and its structure) is represented in multiple editors and a navigational view at the same time. The ideal UI for our users would be to let them close all of those parts (view and editors) and still be prompted to save the model during the app shutdown. Of course, they would be prompted when closing the last part displaying the model but they can decline to save at that point and chose to do so when closing the app. It is a matter of perception. Our average user does not consider it mandatory to close his model just because the parts (views/editors) are closed. For example, it could be cross-referenced from another model whose editor is still up.
In my case it's an external tool process. The user should get a last chance to save the results of the tool. To save the results, the user have to interact with the console. It's not possible to save the results programmatically. ISaveablePart(2) does not work: the process does not have its own view. A ConsolePage (IPageBookViewPage) does not support ISaveablePart (strictly speaking, there is no guarantee, that a ConsoleView is opened).
Will consider for 3.2.
Stefan, do you think this would help address the issue you mentioned today regarding doing saves in the background, and how such jobs can get interrupted due to the workbench shutting down? I'm considering a programmatic API to allow adding a vetoing pre-shutdown listener to the workbench. For example: IWorkbench.addWorkbenchListener(IWorkbenchListener) where IWorkbenchListener has: boolean preShutdown() (for consistency with WorkbenchAdvisor.preShutdown())
For those building RCP apps, do you have any preference for whether clients get notified before or after WorkbenchAdvisor.preShutdown()? I'm currently planning on notifying clients before the advisor.
(In reply to comment #13) I would agree to "before".
Added IWorkbenchListener which has preShutdown and postShutdown methods, and corresponding add/removeWorkbenchListener methods in IWorkbench. In the end, I decided to notify these listeners after the advisor; the rationale being that the advisor has overall control of the app and should have the first chance to veto shutdown. Stephan, what was your rationale for preferring before? Also added WorkbenchListenerTest to the RCP test suite. Teddy, Stephan and others, could you give this a spin?
The workbench listeners are also notified before checking for editors with unsaved changes.
(In reply to comment #15) It meets my demands; whether before or after is not important for me. Thanks.
The workbench listener works as desired. Thanks.
Verified in I20060213-1200.
