Community
Participate
Working Groups
The Tree scroll bar can get out of sync with the top item on Linux. To reproduce in Eclipse: 1. Open a standard SWT development workspace with the UIMain launcher loaded (org.eclipse.core.launcher should be the first project in the tree). 2. Expand the project to display the UIMain class and select it. 3. Exit Eclipse and restart. ->UIMain is selected and the top item. The scroll bar is also at the top/position 0. When you click the scroll bar the tree gets in sync with the scroll bar and shows the first tree item as the top item (the launcher project). NOTES: McQ (01/06/2001 9:02:42 AM) - Scrollbar needs to be forced to update its position. Is this a Tree problem or an ITPUI bug? KR (6/1/01 11:39:31 AM) It's the tree - only happens on Linux. KR (6/1/01 2:02:13 PM) Note that this is only reproducable when there are no editors open. It seems that the selected item is the top item and that the scroll bar is set as if the top item from the last Eclipse session was still the top item. McQ (01/06/2001 4:18:41 PM) - Re "It's the tree - only happens on Linux.": We have already had several cases where they assumed that by working with the scroll bar directly they could get widgets to position their contents, which works some places and not others (and thus is not supported). This could be a similar case. KR (6/4/01 11:42:26 AM) After debugging this for a while I noticed that a bunch of viewers call Tree.getVerticalBar() to restore the old ui state. This is one of the cases where this doesn't work. Tree.setSelection is called to select the previously selected item (at index 10). This automatically sets the top index and the scroll bar selection to 10. Someone (PackageExplorerPart.restoreState) then gets the vertical scroll bar and sets its selection to 9. For some reason the Tree doesn't always update the top index accordingly. KR (6/4/01 12:30:28 PM) It seems that the Tree sometimes gets a selection event for the programmatic scroll bar selection but most of the time doesn't. McQ (05/06/2001 11:04:29 AM) - No further action for June. McQ (26/06/2001 2:19:17 PM) - Time to take another look at this.
PRODUCT VERSION: 114
Not sure when I saw the manual setting the vertical scroll bar selection work. It should always fail on Linux, i.e., the scroll bar will be set but the Tree won't be notified since it was a programmatic change. I experimented with using Tree.showItem with mixed results. On Linux this always scrolls the given item to the top. However, this is spec'd to return without doing anything if the item is already visible. On Windows, since the viewer/widget is not yet visible when the viewer state is restored in JDT, it works as long as the given item is above the selected item. If it is below the selected item the actual top item appears to be off by one. Bottom line: JDT should not try to restore the scroll bar position. It leads to a confusing UI state on Linux. Test case to reproduce what can be seen in Eclipse below: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; /** * This type was created in VisualAge. */ public class Bug_4676 { public static void main(String arguments[]) { Shell shell = new Shell(); Tree tree = new Tree(shell, 0); TreeItem item1 = new TreeItem(tree, 0); TreeItem item1_1 = new TreeItem(item1, 0); TreeItem item1_2 = new TreeItem(item1, 0); TreeItem item1_3 = new TreeItem(item1, 0); TreeItem item; TreeItem item2 = new TreeItem(tree, 0); item1.setText("item1"); item2.setText("item2"); item1_3.setText("item1.3"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item2, 0)).setText("2.1"); (new TreeItem(item1, 0)).setText("1.1"); (new TreeItem(item1, 0)).setText("1.1"); item1.setExpanded(true); tree.setSelection(new TreeItem[]{item1_2}); tree.getVerticalBar().setSelection(0); // tree.showItem(item1); tree.setSize(400, 300); shell.open(); Display display = shell.getDisplay (); while (!shell.isDisposed ()) if (!display.readAndDispatch ()) display.sleep (); } }
Moved to JDT UI for consideration
Claude, can you have a look at this on yr linux box?
yup, it comes up with the second child item at the top, although the vertical scroll bar is at the top.
changed package explorer to no longer save/restore scroll state. Moving to Platform UI - the ResourceNavigate is also saving/restoring the scroll state.
Knut, since you're most familiar with this, could you fix the Navigator up?
We should request SWT API to save/restore the top item of a tree. Like the top index in a table.
Removed the code that saves and restores the position of the horizontal and vertical scrollbars. Trying to restore the horizontal position seems like overkill anyway. Restoring the top index would indeed be nice. We currently set the item selection which moves the selected item to the top. This is sufficient but could be better. Opened SWT bug 24333 asking for getTopIndex/setTopIndex API.
