Community
Participate
Working Groups
I call this on selection on different TreeItems and the only time the width changes is on expansion or contraction if the expansion or contraction makes a different in the total width of all TreeItems (which are in the viewport or not). I'm using TreeItem.getTextBounds() to determine the end location of the text (to draw a graphic). Previously I used TreeItem.getBounds() which on Linux and Windows corresponded to the actual text width, however on Cocoa it's the entire width of the tree. Let me know if you need a snippet and I can make one. I suppose a workaround (and probably even a better implementation for what I'm trying to do) for my problem is to listen to the Paint event and draw the line there based on the data in the event (like Snippet220).
Yes, please add a snippet. I'm not sure what you're trying to do that makes this a problem. Are you drawing something after the item's text?
I will get a snippet soon, and yes, I'm trying to draw something after the end of the text (I'm drawing a line).
Holding on to this for now until Francis provides a test.
Maybe that's related: What I can see (version 3.5.2) is that I can not paint further in the tree than the width of the longest visible item. What I want to do is paint a background color on an entry which spans the tree's width. However this does not work on Mac [carbon] (it actually does on GTK and Win). I am using a tree without a column. TreeItem item= (TreeItem) event.item; Rectangle bounds = item.getParent().getBounds(); event.gc.fillGradientRectangle(bounds.x, event.y, bounds.width, event.height, true); <-- this does not fill the tree's width, event when increasing bounds.width, it does not get painted If this is not related to this bug, drop me a note, I will then create a new bug.
I cc'd Grant, but I was able to modify Snippet283 to demonstrate the bug. We do calculate the right size for the text when sending a MeasureItem or a PaintItem, so I think we should be doing a similar calculation for getTextBounds().
(In reply to comment #4) > If this is not related to this bug, drop me a note, I will then create a new > bug. Marcel, this is a different bug. This bug is on Cocoa.
Created attachment 173818 [details] Fix minor refactoring to remove repeated code, and have getTextBounds call new method for determining width & height of string.
Created attachment 173819 [details] Correct fix Using wrong string in calculateWidth.
Grant, please review for 3.6.1.
I see this on gtk and carbon as well. While I think this behaviour is wrong, I don't think a cocoa fix for it should go into 3.6.1. A better approach would be to fix it for all three (or all two if carbon is discontinued) for 3.7. Also, I don't think it's new, this has probably been wrong on gtk and carbon since 3.3. The test snippet I used: public static void main(String[] args) { String text = "asdf"; Display display = Display.getDefault(); Shell shell = new Shell(display, SWT.SHELL_TRIM); shell.setLayout(new FillLayout()); Tree tree = new Tree(shell, SWT.NONE); new TreeItem(tree, SWT.NONE).setText(text); text += text; new TreeItem(tree, SWT.NONE).setText(text); text += text; new TreeItem(tree, SWT.NONE).setText(text); text += text; new TreeItem(tree, SWT.NONE).setText(text); text += text; TreeItem[] items = tree.getItems(); for (int i = 0; i < items.length; i++) { System.out.println(items[i].getTextBounds(0)); } while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } }
Okay, so we agree it's a bug in any event. I may or may not be able to fix it in GTK, but we'll see.
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.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/165944
While I have moved on from Eclipse, I appreciate a fix to this 10 year old bug!
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/165944 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=225a4f64d5557f0d0511ef5bbff18a358c42862f
This may have caused Bug 566043.
Verified in Eclipse SDK Version: 2020-09 (4.17) Build id: I20200819-0600 OS: Mac OS X, v.10.16, x86_64 / cocoa Java version: 14.0.2
this has caused Bug 566508. My suggestion is to revert the fix
(In reply to Sravan Kumar Lakkimsetti from comment #18) > this has caused Bug 566508. My suggestion is to revert the fix Fix for this bug is reverted, resetting the target.
