Community
Participate
Working Groups
I started using the SWT manifest so I could take screenshots. The toolbar buttons in the sync view are quite a bit bigger than they were (and other view's button's are not). It could be related to the use of a view subtitle. Is this the intented behavior?
Created attachment 23065 [details] Screenshot that shows big toolbar buttons for sync view
This is because we have a drop down button as the first button in the toolbar. Unfortunately, havinbg the sync dropdown first makes the most sense. Now that I know the cause, I seem to recall that this was a known issue.
I've been told this is a bug (or Platform behavior depending on how you look at it) on Windows so I'm moving it to SWT. Unfortunately, this really makes the sync view stick out like a sore thumb. It also causes the toolbar docking behavior of the workbench to act differently (i.e. the toolbar can never be in the tab line). To me, this seems like a serious impediment to using the SWT XP manifests.
This is a dup of a WONTFIX Windows bug that I can't find right now. When we first got XP, I spent a while trying to make it stop doing this and had to give up.
FYI, bug 52871, bug 86194, bug 86286, bug 90767, and bug 91766 all describe this problem.
*** Bug 52871 has been marked as a duplicate of this bug. ***
Couldn't someone create a bogus toolitem to workaround the limitation?
*** Bug 111155 has been marked as a duplicate of this bug. ***
*** Bug 134530 has been marked as a duplicate of this bug. ***
Until I found a non drop-down button to use as the first button I used to use a blank button to avoid this issue (comment#7), which was an annoying hack. It made me wonder if it would be possible to have a 0 or 1px wide dummy 'separator' button that could be added (or would automatically be added) if the first button was a pull-down. Which seems like an annoying hack for Platform/SWT to do. But I think that the current inconsistency between views ends up looking like a hack to users. Personally, the way the toolbar and synch view toolbar blow up has kept me from using the XP manifest. I imagine that when Vista rolls out this will be even more of an issue since not using the XP manifest will make Eclipse look dated.
I think you can create the bogus toolitem and then dispose it shortly thereafter. So the size of it doesn't matter.
Randy, does this actually work?
It's a hunch. I can't imagine that by disposing a toolitem, the others would change their widths. I don't have your snippets loaded in my workspace, but you could probably find out the answer in less time than it takes me to type this comment :-)
*** Bug 135542 has been marked as a duplicate of this bug. ***
Created attachment 38297 [details] modified snippet Here is a modified snippet 150. Clicking on the non-dropdown toolitem disposes them, and appends more items with dropdown style. There is no height increase. But, I had to change the snippet to only display images. If you have text, the original height requirement calculation is different. In that case it doesn't matter if first item is dropdown or not. So the workaround works, except in the following scenario: Finally, if you dynamically add a toolitem containing dropdown style and text (instead of image), the toolbar must be resized taller, or else it will be blank. Try commenting out line 34 and uncommenting 35.
Your snippet seems to do it but I can't seem to create some code that does this without the interactive part. Here is an attempt that fails: import org.eclipse.swt.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class PR_99984 { public static void main(String[] args) { Display display = new Display(); Image icon = new Image(display, 16, 16); GC gc = new GC (icon); gc.setBackground (display.getSystemColor (SWT.COLOR_RED)); gc.fillRectangle (icon.getBounds ()); gc.dispose (); Shell shell = new Shell(display); RowLayout layout = new RowLayout(SWT.VERTICAL); shell.setLayout(layout); ToolBar toolBar0 = new ToolBar(shell, SWT.FLAT | SWT.BORDER); for (int i = 0; i < 8; i++) { ToolItem bogus = i == 0 ? new ToolItem (toolBar0, SWT.NONE) : null; ToolItem item = new ToolItem(toolBar0, false && i != 0 ? SWT.PUSH : SWT.DROP_DOWN); if (bogus != null) bogus.dispose (); item.setImage(icon); //item.setText("Item" + i); } toolBar0.pack(); ToolBar toolBar1 = new ToolBar(shell, SWT.FLAT | SWT.BORDER); for (int i = 0; i < 8; i++) { ToolItem item = new ToolItem(toolBar1, i != 7 ? SWT.PUSH : SWT.DROP_DOWN); item.setImage(icon); //item.setText("Item" + i); } toolBar1.pack(); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
BTW, get rid of the "false & i != 0" part.
*** Bug 137875 has been marked as a duplicate of this bug. ***
Can we reopen this one (if indeed it is the cause of bug 137875. Not quite sure this is a complete dup as the basic problem is that the buttons used to be on the line beside the tabs. HOwever, the buttons certainly are bigger. Makes the UI look like somewhat goofy and very gray.
I seems like there should be some path to convince XP to make the buttons smaller, given Randy's hack. Go ahead and reopen it and add it to the polish list. Those of us that have been running with the manifest file have seen this for ages and got use to it though. I have had a go at whacking XP when this problem first happened in the early XP day and failed but it seems like it's time to try again. One thing though, the "too big" look is really XP look and feel so in the end, even if it can be whacked, there is an argument that says we shouldn't do it. Let's get to the point where we can make that decision before having the argument.
The following workaround works. The "catch": wait until another toolitem gets created before disposing the bogus one. From a JFace point of view, just before asking the first contribution to fill the toolbar, create a bogus toolitem, then dispose it after. public class PR_99984 { public static void main(String[] args) { Display display = new Display(); Image icon = new Image(display, 16, 16); GC gc = new GC(icon); gc.setBackground(display.getSystemColor(SWT.COLOR_DARK_BLUE)); gc.fillRectangle(icon.getBounds()); gc.dispose(); Shell shell = new Shell(display); RowLayout layout = new RowLayout(SWT.VERTICAL); shell.setLayout(layout); ToolBar toolBar0 = new ToolBar(shell, SWT.FLAT | SWT.BORDER); for (int i = 0; i < 8; i++) { ToolItem item = new ToolItem(toolBar0, i == 0 ? SWT.PUSH : SWT.DROP_DOWN); item.setImage(icon); if (i == 1) toolBar0.getItem(0).dispose(); } toolBar0.pack(); ToolBar toolBar1 = new ToolBar(shell, SWT.FLAT | SWT.BORDER); for (int i = 0; i < 8; i++) { ToolItem item = new ToolItem(toolBar1, i != 7 ? SWT.PUSH : SWT.DROP_DOWN); item.setImage(icon); } toolBar1.pack(); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Steve, regarding comment#20 note that even though explorer uses the tall toolbars I'm not sure many consider it the 'XP look' because all office apps use the short ones, and do make use of drop-downs. Side note regarding the future of toolbars on Windows: Ribbons are coming (http://blogs.msdn.com/jensenh/archive/2006/04/17/577485.aspx), and seem to have imitated plugin.xml style extensibility, called RibbonX (google). But since we have very nice view toolbars and menus, the Ribbon thing seems less compelling for Eclipse...
Created attachment 39191 [details] Screenshot I think I have another workaround. The idea is to delay setting the drop down style until after the toolbar has been created. I've added the following method to the Toolbar class: public void fixDropDown() { for (int i = 0; i < items.length; i++) { if ((items[i].getStyle() & SWT.DROP_DOWN) == 0) { continue; } TBBUTTONINFO buttonInfo = new TBBUTTONINFO (); buttonInfo.cbSize = TBBUTTONINFO.sizeof; buttonInfo.dwMask = OS.TBIF_STYLE; OS.SendMessage(handle, OS.TB_GETBUTTONINFO, i, buttonInfo); buttonInfo.fsStyle |= OS.TBSTYLE_DROPDOWN; OS.SendMessage(handle, OS.TB_SETBUTTONINFO, i, buttonInfo); } } and changed the line in createItem (ToolItem item, int index): int bits = item.widgetStyle (); to int bits = item.widgetStyle () & ~OS.BTNS_DROPDOWN; Then I removed the "bogus" button in PR_99984 and "toolBar0.fixDropDown()" after "pack()". The result is attached.
Ok, I'm on it. The question is when is it safe to hammer in the drop down style? I tried doing it directly after the tool item was created and this did not work. Stand by ...
(that was my first attempt too) I think it is safe, since this is how it's done in most MFC applications. In MFC when the toolbar is loaded from a resource file, you can't specify the drop down style in the resource file, so it is done after the toolbar has been loaded. See http://msdn2.microsoft.com/en-us/library/1ke6s1fc.aspx and http://www.codeproject.com/docking/toolbar_droparrow.asp
Specifically, hammering the style back in ToolBar.createItem() after the item has been created in the operating system DOES NOT work. It seems that the tool bar must have been layed out at the smaller size before the style is hammered.
Determining when XP hammers the size is turning out to be quite difficult. I have code that works for simple examples but fails in Eclipse. Still working on it ...
I think I found an even better way. When XP Styles are enabled there is a TB_SETMETRICS message that can be used to specify various padding and spacing sizes. The default Y padding is 7 pixels. If this padding is set to -2, the toolbar height is the same as if there were no drop down buttons. The nasty thing is that it must be set only for toolbars that are oversized (the first button rule seems to work here). I wrote a new native method for Toolbar: public native int fixTB(int handle); implemented as (the -2 constant makes it look exactly the same size if there are no toolbar, but maybe it depends on some other UI constants): JNIEXPORT jint JNICALL Java_org_eclipse_swt_widgets_ToolBar_fixTB (JNIEnv *, jobject self, jint handle) { int hwnd = handle; LRESULT res; TBMETRICS metrics; memset(&metrics, 0, sizeof(metrics)); metrics.cbSize = sizeof(metrics); metrics.dwMask = TBMF_BARPAD | TBMF_PAD; metrics.cxPad = 0; metrics.cxBarPad = 0; metrics.cyPad = -2; res = SendMessage((HWND)hwnd, TB_SETMETRICS, 0, (LPARAM)&metrics); return res; } then in createItem I have added the following code, just before it returns: boolean hasDD = false; for (int i = 0; i < items.length; i++) { if (items[i] != null && (items[i].getStyle() & SWT.DROP_DOWN) != 0) { hasDD = true; } } if (hasDD) { fixTB(handle); } The result will be attached in the screenshot.
Created attachment 39236 [details] Screenshot PS. The first button rule seems to not work after all. The code I attached checks all the buttons. (I should also add that if the perspective bar is placed on the top right, the toolbar is oversized again.)
Created attachment 39237 [details] Views screenshot Console view - "before" and "after"
Created attachment 39239 [details] Toolbar buttons Eclipse, Windows and "Fixed" I have a problem with the last modification. See the attached screenshot. The proposed modification renders the button height incorrectly. Actually, if you compare the buttons with other toolbar buttons the button height is absolutely correct in Eclipse 3.1 RC1a.
Gunnar, the problem is that the toolbar height varries. Your screenshots just show that IE has not worked around the issue, probably because the size of their toolbar is limited and they have plenty of space. If you customize the IE toolbar such that it doesn't have dropdown items, its height will shrink.
You fix seems really dangerous and subject to future badness (font changes, theme changes, Vista changes etc.). I think it's a possibility, but we'd need to be extremely carful. Changes like this, where we have decided what is best for the operating system, have burned us in the past. Particularly scaring is the use of "-2". I'm going to keep investigating this and keep your fix in mind.
This appears to have been introduced AFTER M4 and was evident in M5.
SSQ and I checked the changes to ToolBar and ToolItem and none seemed suspicious. Could someone check the JFace changes?
MVM, Eclipse started shipping with the manifest so that it gets the XP look and feel out of the box. Is this what you were referring to? That may have started aoound M5.
wrt comment #37 , actually no, I mean running M4 and M5 both with the manifest shows M5 with taller toolbars when there is a dropdown present.
I have hacked a path through this that works in both the simple case and in Eclipse. I am refining the code and will be releasing it shortly. Stand by ...
Can I get a "woo-woo!"? Nice hacking, Steve! now if we could just get back those etched separators between the coolitems...
It ain't over quite yet but it's looking good ...
Fixed > 20060425 I had to back away from the fix that would make tool bars with drop down items that had only text or mixed text and images smaller because this caused drawing problems. I was close but just ran out of time. The changes, although awful, are somewhat safer than "-2" (which we still have up our sleaves in case this fails).
To follow up on comment#40... whoohoooo! greatbugfix
eeeeexcellent!
Awesome. Thanks Steve for this great "new look" :-). Verified that N20060426-0010 makes the toolbar height stay small no matter what type the first button is, so it also fixes the 3.1 problems.
Cute :-)
ccing eric
see bug 78839 comment 26 for a side effect of this fix on Vista
Nope. The first thing I tried was removing the work around. It seems Micrsoft had the same "too big" problem that we did and did something to fix it, breaking something else on Vista.
Hello Sorry for asking these questions but I have no more than 6-7 months of experience with Eclipse. I have Eclipse 3.1.2 WTP with the 20060428 updates installed. I don't know whether toolbar buttons should be displayed correctly but they aren't. I failed to download the bugfix mentionned and even if I manage to download it I'm not sure I'd have the knowledge how to install it. Can someone please provide me some help on where can the bugfix be downloaded and how is it installed. Please accept my appologies for bothering the community with silly questions and thanks in advance. Regards, V. Svetoslavov
You'll need 3.2 to get the fix. There's no plan to backport it to 3.1.x because of the complexity of the changes.
When I modify SWT Snippet150 to use the DROP_DOWN style (using either 3.2 or 3.3 M1), the toolbar is still big! Am I doing something wrong? Thanks
Nope. We were only able to (safely) fix button that had only images. The work around we went with caused sizing problems for text and mixed text and images.
Thanks for the quick response. I suspect it's lower priority now, but I have raised bug 155311 to note that drop-down items with text are still broken.
