Community
Participate
Working Groups
M6 If you are computing the size of a tree with large entries it becomes the size of the entire screen even though it may need only half of it. If you run the following code on a 1152 x 864 monitor the width will always be 1152 import org.eclipse.swt.SWT; import org.eclipse.swt.events.FocusEvent; import org.eclipse.swt.events.FocusListener; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.layout.GridData; import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; import org.eclipse.swt.widgets.Tree; import org.eclipse.swt.widgets.TreeItem; /* * (c) Copyright 2001 MyCorporation. * All Rights Reserved. */ /** * @version 1.0 * @author */ public class ResizeTreeTest { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new GridLayout()); final Tree tree = new Tree(shell, SWT.NONE); for (int i = 0; i < 10; i++) { TreeItem item = new TreeItem(tree, SWT.NONE); item.setText("Fetching children of HEAD: Fetching remote CVS children for ':extssh:tod@dev.eclipse.org:/home/eclipse'...: 0% done"); } shell.addFocusListener(new FocusListener() { /* (non-Javadoc) * @see org.eclipse.swt.events.FocusListener#focusGained (org.eclipse.swt.events.FocusEvent) */ public void focusGained(FocusEvent e) { shell.setSize(tree.computeSize(SWT.DEFAULT, SWT.DEFAULT)); } /* (non-Javadoc) * @see org.eclipse.swt.events.FocusListener#focusLost (org.eclipse.swt.events.FocusEvent) */ public void focusLost(FocusEvent e) { // XXX Auto-generated method stub } }); tree.setLayoutData(new GridData(GridData.FILL_BOTH)); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
FIxed in HEAD for Windows. Leaving bug open for the minute because there are platform differences in the behaviour of Tree.computeSize: Windows/Mac - width and height based on root items only Motif/Photon - width based on first 50 (or less) visible items, height based on root items only GTK - width and height based on visible items
Ran the following example to show the different results per platform: public static void main (String [] args) { Display display = new Display (); final Shell shell = new Shell (display); shell.setLayout(new GridLayout()); final Tree tree = new Tree(shell, SWT.BORDER); for (int i = 0; i < 4; i++) { TreeItem item = new TreeItem(tree, SWT.NONE); item.setText("item "+i); for (int j = 0; j < 4; j++) { TreeItem subItem = new TreeItem(item, SWT.NONE); subItem.setText("item "+i+" "+j); for (int k = 0; k < 4; k++) { TreeItem subsubItem = new TreeItem(subItem, SWT.NONE); subsubItem.setText("item "+i+" "+j+" "+k); } } } tree.addListener(SWT.Expand, new Listener() { public void handleEvent(Event e) { System.out.println(tree.computeSize(SWT.DEFAULT, SWT.DEFAULT)); shell.layout(true); } }); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } Results have changed slightly since last reported: Windows/Mac/Motif/Photon - width and height based on root items only GTK - width and height based on visible items - but not exactly correctly - seems to miss the expansion of the first level
*** Bug 93977 has been marked as a duplicate of this bug. ***
*** Bug 85533 has been marked as a duplicate of this bug. ***
Is behavior "Windows/Mac/Motif/Photon - width and height based on root items only" is the right one? Let the container decide optimal size of the tree based on a layout selected and correct children size returned by Tree control. This is critical for us.
I think the correct behaviour for computeSize is to return the size required to show all items that are visible at the time computeSize is called. The reason I think this is the correct behaviour is because currently there is no way to find out this size.
Created attachment 22583 [details] Proposed fix for win32 computeSize Running against HEAD as of June 8, 2005 it appears that it still only returns the height of the root items for computeSize() on Win32. If it is agreed that the correct behavior is to return the height of all of the visible items then the attached patch seems to fix the issue. The only change I'd still like to make is to take into account wether the scroll bars are actually showing or not. Right now the horizontal scrollbar's height is always included in the total height so there is gap displayed at the bottom of the control when the scrollbar isn't currently being displayed.
*** Bug 27213 has been marked as a duplicate of this bug. ***
*** Bug 165296 has been marked as a duplicate of this bug. ***
*** Bug 191262 has been marked as a duplicate of this bug. ***
Can the 1-line patch from comment 7 be committed? Or maybe some feedback as to why the patch is not usable? As far as the scrollbars always being included in the resulting size, at least this is consistent with the way Composite works already, even if it's not the desired result.
It seems that GTK is wrong, not the other platforms. In any case, it's too late for 3.3.
I don't see why the win32 behavior is "more better" than gtk's. One could argue that getting a consistent result back is useful, but even that's flawed logic since the number of root treeitems can change over time, or the font height could change. If a consistent result is better, why not just return the size of the trim?
Created attachment 71350 [details] patch for osx, motif and photon This patch changes Tree.computeSize() on osx, motif and photon to match gtk.
fixed > 0723, all platforms now behave like gtk (computeSize(...) considers all available items)
