Community
Participate
Working Groups
Build Identifier: Eclipse e4 Runtime Support 0.9.1.v20091009 (org.eclipse.e4.runtime.feature.feature.group) Hi, I am trying to print some message to the status bar of my e4 application. Therefore, I injected the IStatusLineManager @Inject IStatusLineManager statusLine; When I run my e4 application I get an InjectionException error. Are you planning to support this feature in upcoming e4 releases? Best Regards, Matthias Reproducible: Always
Sounds like a good idea to me, +1 to have IStatusLineManager as one of the services in the context.
+1
How would the developer control whether they want the status bar or not? Not every RCP application may want or need this. In 3.x this was controlled programmatically by advisors I believe. Also, I know that for Eclipse anyway that there are some users that wish they could remove the status bar for more vertical screen space but am unable to.
(In reply to comment #3) > How would the developer control whether they want the status bar or not? Not > every RCP application may want or need this. In 3.x this was controlled > programmatically by advisors I believe. > > Also, I know that for Eclipse anyway that there are some users that wish they > could remove the status bar for more vertical screen space but am unable to. Couldn't that be achieved utilizing an Addon for this?
(In reply to comment #4) > Couldn't that be achieved utilizing an Addon for this? Possibly. This hasn't been investigated yet. I was posing the question to get some suggestions.
I think the UI component StatusLine should be optional but the IStatusLineManager should always be in the context. This way the StatusManager could be used inpedendent of the UI component. AFAIK this would be the same as in 3.X.
(In reply to comment #6) > I think the UI component StatusLine should be optional but the > IStatusLineManager should always be in the context. Yes, we would have to provide a simple headless implementation by default.
(In reply to comment #6) > I think the UI component StatusLine should be optional but the > IStatusLineManager should always be in the context. This way the StatusManager > could be used inpedendent of the UI component. > > AFAIK this would be the same as in 3.X. Lars' suggestion sounds more convenient, +1
(In reply to comment #3) > How would the developer control whether they want the status bar or not? Not > every RCP application may want or need this. In 3.x this was controlled > programmatically by advisors I believe. > > Also, I know that for Eclipse anyway that there are some users that wish they > could remove the status bar for more vertical screen space but am unable to. Why not model the status line? TrimmedWindows have TrimBars. One would add the status line as a WindowTrim at the bottom. If this is indeed possible, then why not model status contributions to the status line as well?
(In reply to comment #9) > Why not model the status line? TrimmedWindows have TrimBars. One would add the > status line as a WindowTrim at the bottom. So I guess you are suggesting a default IStatusLineManager implementation be provided as an MToolControl, correct? > If this is indeed possible, then why not model status contributions to the > status line as well? This would be possible. People would just add MToolControl to the bottom trim bar.
(In reply to comment #10) > (In reply to comment #9) > > Why not model the status line? TrimmedWindows have TrimBars. One would add the > > status line as a WindowTrim at the bottom. > > So I guess you are suggesting a default IStatusLineManager implementation be > provided as an MToolControl, correct? > > > If this is indeed possible, then why not model status contributions to the > > status line as well? > > This would be possible. People would just add MToolControl to the bottom trim > bar. Please be forgiving, I am no expert, but I would expect there to be a model element StatusBar (MStatusBar) corresponding to ToolBar. This StatusBar could then be added as a Window Trim - bottom. In line with 3.x this StatusBar may provide a StatusLine with the shared message area and other global stuff (progress monitor?). Furthermore one may have a model element StatusControl (MStatusControl) corresponding to ToolControl (if I understand its meaning). This StatusControl would correspond to a 3.x ContributionItem. As such a StatusControl would need a ClassURI to a POJO class, providing, e.g., the 3.x ContributionItem.fill() stuff. Adding a StatusBar is optional, as is adding one or more StatusControls to the StatusBar. I don't know, whether, for example, StatusControl and ToolControl would end up as the same thing with different names. A default implementation of IStatusLineManager could always be present in the context, as suggested above. If there is no StatusBar, it might do nothing. Otherwise it would write to the shared message area of the StatusLine.
Brian, IIRC you mentioned in your EclipseCon talk that only 1-2 commits are missing to make this work. If I remember incorrectly, please remove yourself again from the assignee.
Lars: My comments were in relation to exposing the appropriate IStatusLineManager from the Eclipse 3.x layer, filed as bug 378395. (Which has a corner case for which I'm experimenting with a solution, to do with calling IActionBar#updateActionBars() vs IStatusLineManager#update().) There may be a simple and straightforward implementation that will meet the needs of many pure E4 apps, but I haven't thought about this and unfortunately don't have cycles for that at the moment.
Thanks Brian for the clarification, I also was thinking about the use case of Bug 332499. In Eclipse 4 RCP we currently don't support a default status line, so I mark this bug as WONTFIX for the moment. In case we offer a default status line, we should reconsider this request.
