Community
Participate
Working Groups
Surprisingly it is not.
This bug is different from bug 332499 as it is with the compatibility layer where there is an IStatusLineManager already.
It's easy to expose the WorkbenchWindow's IStatusLineManager to its context. But then any part would have direct access to the window's IStatusLineManager rather than go through the sub-manager managed by the part's IActionBars. We could set the part's action-bar's IStatusLineManager in its context, but that could be seen to violate the spirit of the IActionBars, whose docs say: * A part may also contribute new actions to the action bars as required. To do * this, call <code>getMenuManager</code>, <code>getToolBarManager</code>, or * <code>getStatusLineManager</code> as appropriate to get the action target. * Add the action(s) to the target and call <code>update</code> to commit * any changes to the underlying widgets. The last line could be interpreted as meaning that changes are expected to be pushed using IActionBars#updateActionBars(), rather than explicitly call IStatusLineManager#update().
I'm thinking that we can expose an IStatusLineManager wrapper that delegates to the underlying IStatusLineManager except for #update() which will call getActionBars().updateActionBars().
Brian, do you happen to know any workaround for accessing the IStatusLineManager from an e4 view running inside the workbench?
I should have closed this bug as WONTFIX: my original desire had been to allow background services to display information on the status, but that doesn't really fit in with the workbench policies. But now that we support `e4view`, we should make this available via DI. As a hack: I think you'll need to do as org.eclipse.ui.internal.ViewSite#initializeDefaultServices() and org.eclipse.ui.internal.e4.compatibility.ActionBars do: - get the IWorkbenchPage - cast to WorkbenchPage - call WorkbenchPage.getActionBars().getStatusLineManager() - build a SubStatusLineManager around it I suppose we could do this as an IContextFunction.
Created attachment 266599 [details] context function Great tip! I've crafted together the attached context function. It looks up the required things from the context and creates a SubStatusLineManager. It uses DS annotations for easy registration with the DI system in order to allow injection of IStatusLineManager objects into parts.
Comment on attachment 266599 [details] context function Cool! A few nits: - You'll want that RAT to run on the part's context, rather than the provided context (e.g., a part could have allocated multiple child contexts for its own use). - You should record the SubStatusLineManager in the part context (as IStatusLineManager.class) and try retrieving it (with IEclipseContext.getLocal()) to avoid creating multiple sub line managers. We should build this into the workbench: we shouldn't need each part to have their own RAT to track the status visibility.
(In reply to Brian de Alwis from comment #7) > - You'll want that RAT to run on the part's context, rather than the > provided context (e.g., a part could have allocated multiple child contexts > for its own use). That's a good point. It actually just needs to run on the context that has the active part set. Is that the part context? > - You should record the SubStatusLineManager in the part context (as > IStatusLineManager.class) and try retrieving it (with > IEclipseContext.getLocal()) to avoid creating multiple sub line managers. Ah I wasn't aware of this. I thought the context would cache whatever I return in my ContextFunction. > We should build this into the workbench: we shouldn't need each part to have > their own RAT to track the status visibility. Yes, the goal is to have that available in the workbench. Maybe this could avoid the RAT as well as the OSGi service part altogether. Happy to submit a review. Do you have a pointer to the code that deals with part activation?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
