Bug 339133

Comment 1 Joseph Carroll 2012-08-21 15:39:09 EDT

Also reference forum message: 
http://www.eclipse.org/forums/index.php?t=rview&goto=902705#msg_902705

Comment 2 Eric Moffatt 2012-08-23 14:15:22 EDT

Of the images on the forum the one I think is really wrong it the one where the toolbar doesn't wrap (as it does in the 3.x case). The other behavior is the result that the CTabFolder has no idea what the controls it has are for, it just wraps them as we would in the main toolbar, rightmost first...

Comment 3 Dirk Segelhorst 2013-03-19 05:11:02 EDT

Anything new about this? We are facing the same problems with non wrapping view toolbars in E4.2. As we have many contributions to the view toolbars in our RCP this will be a blocker for us.

Comment 4 Paul Webster 2013-03-19 06:50:09 EDT

No one is looking at this at the moment.

PW

Comment 5 Jens Kuebler 2013-03-19 09:35:45 EDT

A ViewFormLayout was used back in 3.x where as RowLayout#layoutHorizontal is being used in 4.x. The RowLayout gets two ToolBars as controls : The main toolbar for contributions and the view dropdown toolbar for additional items. Wrapping does occur between the toolbars but not within the toolbar items.
The Toolbar itself has no layout set but I can't where a layout might be triggered for the toolbar. Do you have a suggestion how to implement this behavior best?

Comment 6 Jens Kuebler 2013-05-03 05:04:03 EDT

Created attachment 230445 [details]
Alternative Layout based on RowLayout

I tweaked the RowLayout a little bit within the layoutHorizontal to wrap the toolbars properly. The current package is of course not the place this should reside in.
What do you think is the best option here?
Subclass RowLayout or change the original RowLayout?

Comment 7 Eric Moffatt 2013-05-03 11:06:48 EDT

After a look it does appear that we're setting the SWT.WRAP flag on the TB so I'm passing this on to the SWT folks for a look.

I'm testing this using the Breakpoints view which has enough tool items to show the non-wrapping behavior if you make the stack narrow...

Comment 8 Jens Kuebler 2013-07-25 12:39:26 EDT

Any target milestone from the SWT team?

Comment 9 Markus Keller 2014-08-25 09:30:16 EDT

RowLayout was not made for children that
- may be wider than the parent Composite
- do internal wrapping when the parent is too narrow for a single item

Bug 394372 is for the bad rendering of part toolbars in Eclipse. It's not clear whether this enhancement request is necessary to fix that bug.

Note that even if this enhancement is implemented, the resulting experience will often be suboptimal. SWT controls can only be laid out as a single rectangle. E.g. if a composite contains a narrow control followed by a very wide control that does internal wrapping, then the rest of the first row is inevitably wasted:

|Narrow                    |
|Wide1 Wide2 Wide3 Wide4   |
|Wide5 ...                 |

The right solution for the client is to put the "Narrow" and the "Wide*" controls into the same parent and layout everything together.


public class Snippet49_withLayouts {

public static void main (String [] args) {
	Display display = new Display ();
	final Shell shell = new Shell (display);
	final ToolBar toolBar = new ToolBar (shell, SWT.WRAP);
	for (int i=0; i<12; i++) {
		ToolItem item = new ToolItem (toolBar, SWT.PUSH);
		item.setText ("Item " + i);
	}
	
	/* GridLayout works fine. */
	shell.setLayout(new GridLayout());
	toolBar.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, false));
	
	/* RowLayout was not made for children that may be wider than the parent
	 * and then start internal wrapping. */
//	shell.setLayout(new RowLayout());
	
	shell.pack ();
	shell.open ();
	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
}
}

Comment 10 Lars Vogel 2019-11-27 07:09:54 EST

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.

If you have further information on the current state of the bug, please add it.
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.

If the bug is still relevant, please remove the stalebug whiteboard tag.