Community
Participate
Working Groups
M6 It's not possible to alter the height of widget contributions. They are constrained by the height of their containing toolbar. This causes something as simple as a Combo to clipped in an unattractive way on OS X.
Kim, let's go over this tomorrow. My suspicion is that the issue is with the TB's 'computeSize' not working correctly. Noe that the 'minimized' stacks cause the bottom border to grow when you drag a stack there so the Trim Manager understands about height; it's just getting an incorrectly calculated 'preferred' height. It's might be a flavor of bug 177818...is there any change if you add a button to the TB?
Just to capture what Kim and I have discovered... On a Mac the SWT implementation of ToolItem#computeSize uses Control#getMinimumHeight to determine the height of SEPARATOR items hosting controls. The getMinimumHeight method is only used in the ToolItem's computeSize. The base implementation in Control returns 0 and the only override is in Combo which (although it looks at the font metrics) returns a hard-coded 26. This means that this calculation is -guaranteed- to give incorrect results in all cases. Changing the ToolItem's computeSize to simply defer to it's hosted control's computeSize appears to work fine (and would seem to make more sense). My suspicion is that bug 177818 is caused by a similar implementation on Linux.
Transferring to SWT since we've verified that, given a correctly sized ToolBar will result in the trim being displayed correctly... Steve, Kim's been over this with Silenio but he's leery of making the change, fearing unexpected side-effects. Without it I can't see any way of making ToolBars support controls on the Mac. You can't even beat it into submission by wrapping it in a Composite that has a specifically contructed Layout designed to return the correct size because 'computeSize' isn't being used. In fact you get two completely different results; a Combo not wrapped in a Composite gets 26 and a Combo wrapped in a Composite with a FillLayout gives you 0 (from the Control's default impl). What's your take ?
Marking as majow since it completely prevents us from using controls in ToolBars (i.e. Trim) on the Mac.
I will discuss it with Silenio on Monday.
Here's a snippet to try: /******************************************************************************* * Copyright (c) 2000, 2007 IBM Corporation and others. * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * IBM Corporation - initial API and implementation *******************************************************************************/ package testtbs.actions; /* * ToolBar example snippet: place a combo box in a tool bar * * For a list of all SWT example snippets see * http://www.eclipse.org/swt/snippets/ */ import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class TestTB { public static void makeComboTB(Shell shell, int y, boolean useComposite) { ToolBar bar = new ToolBar(shell, SWT.BORDER); bar.setLocation(10,y); ToolItem sep = new ToolItem(bar, SWT.SEPARATOR); Composite parent = bar; if (useComposite) { parent = new Composite(bar, SWT.NONE); } Combo combo = new Combo(parent, SWT.READ_ONLY); for (int i = 0; i < 4; i++) { combo.add("Item " + i); } combo.select(1); combo.pack(); sep.setWidth(combo.getSize().x); if (useComposite) sep.setControl(parent); else sep.setControl(combo); bar.pack(); } public static void makeTextTB(Shell shell, int y, boolean useComposite) { ToolBar bar = new ToolBar(shell, SWT.BORDER); bar.setLocation(10,y); ToolItem sep = new ToolItem(bar, SWT.SEPARATOR); Composite parent = bar; if (useComposite) { parent = new Composite(bar, SWT.NONE); } Text text = new Text(parent, SWT.BORDER); text.setText("Test String"); text.pack(); sep.setWidth(text.getSize().x); if (useComposite) sep.setControl(parent); else sep.setControl(text); bar.pack(); } public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); makeComboTB(shell, 10, false); makeComboTB(shell, 50, true); makeTextTB(shell, 100, false); makeTextTB(shell, 150, true); shell.setBounds(100,100,400,400); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Created attachment 66116 [details] Shows sizing errors occurring on the Mac My suspicion is that I can make these worse by choosing a larger than default font...
P.S. I'm not Pascal, I'm really Eric Moffatt
Created attachment 66118 [details] Shows the same SWT code on Vista
We have a fix for this problem, but it requires the addition of new API. The new API is ToolItem.getSize()/ToolItem.setSize(int, int)/ToolItem.setSize(Point). The application needs to call ToolItem.setSize() in places where it called ToolItem.setWidth(). That way it can specify the appropriate height for the control of the ToolItem.
McQ, here's the defect with the API request that we've talked about. Is there any chance that you could +1 this today to allow Steve to get the changes in tonight's build?
Hmmm, I waas going to attach a patch with the platform changes but a quick search shows that we only use 'setWidth' in -one- place, JFace's 'ControlContribution'...I'll just wait for the API to show up.
The PMC has approved the new API.
*** Bug 177818 has been marked as a duplicate of this bug. ***
Still review the code...
Just to keep folks in the loop...Steve ran into problems with the Windows implementation of the newly proposed API and ran out of time. AFAIK he hasn't given up though...;-).
New API is required to fix this problem. We are not going to address it in 3.3.1.
*** Bug 207246 has been marked as a duplicate of this bug. ***
is there a patch available? can you please attach them to this bug. thanks
Created attachment 91260 [details] screenshot of trim I'm seeing a regression on Eclipse 3.4M5 on Linux/GTK. A trim that used to work now has a height of one pixel (see screenshot: the xmag window shows the enlarged toolbar). I am using a menu contribution that adds a control that extends WorkbenchWindowControlContribution: <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:org.eclipse.ui.trim.command2?after"> <toolbar id="id.toolbar"> <control class="trim.MyTrimWidget" id="id.trim" /> </toolbar> </menuContribution> </extension> If I add a command to the toolbar it is properly rendered. I suspect that the ToolBar correctly calculates it's height from the ToolItem that is used for the command in that case. Is there a known work around? Are there plans to address this for 3.4?
This appears to be a regression on bug 177818
We have worked around the problem by contributing a command to the toolbar. We disable the command after the toolbar is realized on screen and set the label to the empty string which makes the toolbar button "invisible". Is there any update on the progress for adding new API (comment #17) to address this bug? We talked to Eric Moffat at EclipseCon and he mentioned that setting the height on the toolbar would not work on windows and therefore it was not added. It would be great if this could be fixed in time for 3.4.
ToolItem uses the image height to determine its height if an image is set. I've successfullly used the following workaround: bc.. toolBarManager.add(new ControlContribution("Find") { @Override protected Control createControl(Composite parent) { // create control here final Text findText = toolkit.createText( ...snip... // hack to workaround bug 183003 Display.getCurrent().asyncExec(new Runnable() { public void run() { if (findText.isDisposed()) { return; } final Point size = findText.computeSize(SWT.DEFAULT, SWT.DEFAULT); toolBarManager.add(new ContributionItem() { private ToolItem widget; @Override public void fill(ToolBar parent, int index) { if (widget == null && parent != null) { int flags = SWT.PUSH; ToolItem ti = null; if (index >= 0) { ti = new ToolItem(parent, flags, index); } else { ti = new ToolItem(parent, flags); } ti.setData(this); // create an image the height of the text field final Image image = new Image(Display.getCurrent(),1,size.y); GC gc = new GC(image); gc.setBackground(parent.getBackground()); gc.fillRectangle(image.getBounds()); gc.dispose(); ti.addDisposeListener(new DisposeListener() { public void widgetDisposed(DisposeEvent e) { image.dispose(); } }); ti.setImage(image); widget = ti; } } }); toolBarManager.update(true); } }); return control; } });
It seems that nothing happened here for quite some time. Is there anything that could be done to have it solved then? The workaround provided doesn't help when the contribution is done via extension point.
What is the status on this bug? we switched from an old syntax to the new syntax (https://bugs.eclipse.org/bugs/show_bug.cgi?id=330106) and now we have clipping on Linux. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=365042) Do we have to revert back to the old syntax?
Paul, is there a way that we could incorporate the given workaround into Eclipse 4's rendering story. We would identify that a given contributed toolbar only contains controls and create a 'null image' that is as tall as the max of the various control's computeSize() values. (Un)Fortunately we already have a test case for this...the Jazz trim on Linux.
Created attachment 269969 [details] Git Staging view; filter ControlContribution cut off on Linux/GTK 3 EGit is running into this on Linux/GTK 3 with the filter Text field in the toolbar of the staging view. It's cut off at the bottom.
Created attachment 269970 [details] Git History page; dynamic "Find" ControlContribution cut off on Linux/GTK 3 Same problem in the history view with the Git History page; here it's a dynamic ControlContribution (a Composite containing a Text widget and a Toolbar).
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
