| Summary: | [RCP] [Contributions] [ViewMgmt] Application-level status is overridden by views | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Edgar <n.a.edgar> |
| Component: | UI | Assignee: | Boris Bokowski <bokowski> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ob1.eclipse, pascal, semion |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Nick Edgar
Reassigning bugs in component areas that are changing ownership. Current implementation supports 2 levels of messages - error and usual, which are held in two buffers, on one for each type. Setting new message causes disappearing of the old message from the same type. If both types of messages are set, error message is displayed. As far as I understand, to support specific behavior of application's messages we at list need to add one more level (let's call it application level) with the lowest priority. This may be simply done in StatusLine. In addition we can create interface IStatusLineManger2 (which extends IStatusLineManager and defines some new methods for setting messages of new type) and implement new methods in StatusLineManager. If we shall stop on this, we, actually, will not solve the problem, because new API will be accessible from everywhere, and this will not prevent views and editors form deleting application level messages. One more possible solution (possibly without creating new interface) may be done by using some internal proxy of StatusLineManger in the place, which is accessible from application's level only - in ActionBarConfigurer. This proxy should implement existing IStatusLineManager and contains real StatusLineManager, as its member. All its methods, excluding setMessage(), will be implement as calls of corresponding methods from real manager, just as setMessage() will directly call some new method like setApplicationMessage() from StatusLine. Yes, this seems like the change is not worth the effort.
For applications that want to make sure that their message stays on the status line there is an easy workaround - create a separate area on the status bar in the ActionBarAdvisor override, something along the lines:
private StatusLineContributionItem statusLineItem;
protected void makeActions(final IWorkbenchWindow window) {
statusLineItem = new StatusLineContributionItem("ModeContributionItem"); //$NON-NLS-1$
...
}
protected void fillStatusLine(IStatusLineManager statusLine) {
statusLine.add(statusLineItem);
statusLineItem.setText("Status message of this application");
}
Marking as a won't fix: there is really no differentiation between status messages set by views and by applications; a new API will be requred to introduce it.
|