Bug 332499

Comment 1 Oleg Besedin 2010-12-14 10:19:31 EST

Sounds like a good idea to me, +1 to have IStatusLineManager as one of the services in the context.

Comment 2 Lars Vogel 2010-12-14 11:11:35 EST

+1

Comment 3 Remy Suen 2011-01-24 16:48:58 EST

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.

Comment 4 Sebastian Schneider 2011-01-24 16:57:47 EST

(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?

Comment 5 Remy Suen 2011-01-24 17:21:20 EST

(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.

Comment 6 Lars Vogel 2011-01-24 17:42:31 EST

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.

Comment 7 Remy Suen 2011-01-24 18:06:37 EST

(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.

Comment 8 Sebastian Schneider 2011-01-25 05:47:58 EST

(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

Comment 9 Karl Weber 2011-10-23 04:24:03 EDT

(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?

Comment 10 Remy Suen 2011-10-24 11:40:04 EDT

(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.

Comment 11 Karl Weber 2011-10-24 15:47:25 EDT

(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.

Comment 12 Lars Vogel 2014-03-31 15:57:37 EDT

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.

Comment 13 Brian de Alwis 2014-03-31 16:48:20 EDT

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.

Comment 14 Lars Vogel 2014-03-31 17:13:57 EDT

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.