Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] a note about status line contributions


Issues 1 and 2 sound like bugs in Eclipse UI / JFace.

Issue 3:

Passing SWT.DEFAULT to computeSize(), is the normal way it should be 
The intent is for the parent widget to ask the child widget for its 
preferred size, and then layout accordingly. 
The parent then sets the size and position of the child with the results 
of the layout. 
So it's normal for the label's set width and height to be ignored by 

In this case, Label's computeSize implementation is not what you want.  It 
calculates the preferred size based on its text, whereas you want a fixed 
So here, overriding it as you're currently doing is the right answer. 
Note that you also need to be aware of platform and system font settings, 
and should not hardcode a pixel width.  It should be based on the label's 
default font, e.g. space for "Ln 9999 Col 999".

Issue 4:

Part of the problem here is that the status line does not currently 
re-layout when items are added or removed from it.  Maybe it should (the 
toolbar does), but this could also be annoying if the height changes when 
switching to and from a Java editor, causing a full relayout of the 

If we don't believe it should resize, then we should be passing the height 
of the client area to the children's computeSize, and you should just 
return this value.  We're currently passing SWT.DEFAULT for the height, 
and ignoring the resulting height, which is wrong.

Where did you get the number 10 for the height of your label?  Is it just 
a random number since we're currently ignoring it? 
We should not have such hardcoded numbers anywhere in our code, so if you 
did find it somewhere please let me know.


"David Springgay/OTT/OTI" <David_Springgay@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/28/01 10:04 AM
Please respond to platform-ui-dev

        To:     platform-ui-dev@xxxxxxxxxxx
        Subject:        Re: [platform-ui-dev] a note about status line contributions

I have created a PR with your concerns,  Bug 6383, and included you on the
CC list.


                    Maetzel/ZRH/OTI"               To: 
                    <Kai-Uwe_Maetzel@xxxxxx        cc:   
                    m>                             Subject: 
[platform-ui-dev] a note about status line 
                    Sent by:                       contributions     
                    11/28/01 05:13 AM  
                    Please respond to  

In build 20011127 text editors derived from AbstractTextEditor and
associated with an instance of BasicTextEditorActionContributor show 
information in the window's status bar. By default the status information
consists of three status fields showing the cursor position, the input
mode, and whether the editor's input is read only or writable.

While implementing this feature I found a few issues I'd like to bring up.
It seems to me that in order to achieve a correctly working status line
contribution a rather fond understanding of some of the workbench's and
JFace internals is required. One reason for that might be that I took the
wrong path to implement things. If so please let me know how to make it

BasicTextEditorActionContributor extends EditorActionBarContributor
overriding contributeToStatusLine as follows:

public void contributeToStatusLine(IStatusLineManager statusLineManager) {
     for (int i= 0; i < STATUSFIELDS.length; i++)

Issue 1:

- I'd expect contributeToStatusLine to be called every time the first
instance of a particular editor type is created. Indeed it is called for
each newly created editor. In order to avoid contribution items per 
it is necessary to contribute the same contribution items on every call.
This way the status line manager recognizes that they are already there 
avoids duplications.
- That the contributed items must be the same can easily be overlooked and
so I did.

As the status line manager can be configured with contribution items I
implemented a StatusLineContributionItem. The code snippet below is 
from the working code. There are the following issues:

Issue 2:

- The label added to the widget hierarchy needs to have its data pointer
set the contributing item. If not, the contribution item is never removed
from the status line. The algorithm that determines which items are to be
added and removed relies on a "valid" data pointer.
- That the contributed widget must have its data pointer being set to the
contribution item can easily be overlooked and so I did.

Issue 3:

- The label added to the widget  hierarchy is a custom made widget
redefining computeSize. Explicitly setting the size of the label does not
have any effect. StatusLineLayout always passes SWT.DEFAULT to the
computeSize method of the contributed widgets which usually causes them to
ignore their size settings. I am not aware of another way to ensure a
certain width of the status line contribution rather then defining a 
- That the size hints are ignored can easily be overlooked and so I did.

Issue 4:

- As the custom widget ensures a fixed width, it also has to know the
height. The information about which height is expected can only be found 
the code.

public class StatusLineContributionItem extends ContributionItem 
IStatusField {

     static class StatusLineLabel extends CLabel {

          private Point fFixedSize;

          public StatusLineLabel(Composite parent, int style) {
               super(parent, style);
               fFixedSize= new Point(<computed width>, 10);

          public Point computeSize(int wHint, int hHint, boolean changed) 
               return fFixedSize;

     private String fText;
     private Image fImage;
     private StatusLineLabel fLabel;

      * Creates a new item with the given id.
      * @param id the item's id
     StatusLineContributionItem(String id) {


      * @see IContributionItem#fill(Composite)
     public void fill(Composite parent) {
          fLabel= new StatusLineLabel(parent, SWT.SHADOW_IN);

          if (fText != null)

          if (fImage != null)


platform-ui-dev mailing list

platform-ui-dev mailing list

Back to the top