Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] Deleting all child TreeItems causes parent to collapse | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Edgar <n.a.edgar> |
| Component: | SWT | Assignee: | Project Inbox <swt-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Felipe Heidrich <eclipse.felipe> |
| Severity: | normal | ||
| Priority: | P3 | CC: | grant_gayed, mlists, pinnamur |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
The SWT tests should probably have coverage for cases like this. Would also be nice if the SWT tests ran on GTK <g>. In a way I think gtk behaviour is acceptable. Since it is not possible to expand an item with no children it is consistent to collapse the TreeItem when the last child is removed. I think it makes more sense to change windows to do the same thing. Allowing it to collapse will be problematic. For example, the tree viewer lazily populates child items. It creates a dummy item for the +, then during an expand callback, it deletes the dummy item and creates the actual child items. If it collapsed while deleting the dummy item, that would negate the expansion. Relate to: http://bugzilla.gnome.org/show_bug.cgi?id=50054 I can add a expand flag in our TreeItem and assure the expand state is honour when new items are added or the expand state request *** Bug 26410 has been marked as a duplicate of this bug. *** *** Bug 253982 has been marked as a duplicate of this bug. *** Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info. This is a duplicate of bug#208939. The patch for this bug is already available in bug#208939 The patch required for fixing this is available at bug#208939. So, closing as duplicate.. *** This bug has been marked as a duplicate of bug 208939 *** |
build I20030723 GTK 2.2 If you delete all children under an expanded TreeItem, it loses its expanded state. This is an unexpected side-effect. The following code shows the problem. It should print true. This works on Windows and Motif, but not GTK. public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); Tree tree = new Tree(shell, SWT.NONE); TreeItem parent = new TreeItem(tree, SWT.NONE); parent.setText("parent"); TreeItem child1 = new TreeItem(parent, SWT.NONE); child1.setText("child1"); parent.setExpanded(true); child1.dispose(); // The following two lines are not really necessary // to show the loss of expansion state, // but serve to illustrate wanting to replace the children // with a new set without losing the expansion state. TreeItem child2 = new TreeItem(parent, SWT.NONE); child2.setText("child2"); // the following should print true System.out.println(parent.getExpanded()); display.dispose(); } Ideally, SWT would enforce consistent semantics for basic operations like item deletion across platforms. In my view, this side effect is an OS bug that SWT should work around. Similar cases have come up in the past. See bug 6035. Here the complaint was that Motif didn't collapse the parent while Windows did. However the fix seems to have been to make Windows not collapse the parent since that's the current behaviour. See also bug 26410 and bug 3840. Bug 3840 shows that, while the free collapse seems innocuous, it can actually be very confusing to developers. Actually, 3840 probably shows the remnants of the old Windows behaviour: trying setExpanded(true) on an empty parent doesn't work. This was also causing one of our viewer tests to fail: AbstractTreeViewerTest.testRefreshWithAddedChildren. This is a regression test to ensure that no dummy node (for the lazy expansion thing) is created when the viewer refreshes an empty expanded node and discovers new children. We can't test this if the OS doesn't allow you to create an empty expanded node. For now, I'll add a check in the test for the free collapse, but I'd like to take this workaround out if this bug is fixed.