Community
Participate
Working Groups
Eclipse 20021114, default configuration (no customizations) I have noticed the package explorer does not always bring the class file selected into view. With a new workspace I import the UI modules from CVS (select Head -> Modules - > platform-ui). I then import all required binary plugins via the import facility. At this point in the java perspective I have no open editors and the package explorer tree is collapsed. Now open the type "volume" via the type selection dialog (ctrl-shift-t). Note the package explorer does not position correctly. If you scroll down you will see the proper expansion has occurred, and volume is selected. Now select the class "welcomeeditor". The package explorer positions correctly. Finally select the class "swt". Again the package explorer positions correctly. Now select the class "writer". The package explorer does not correctly position. Note this class is right after "volume" so no expansions were required, only a reposition. Now try the sequence swt, volume, writer. Volume is not correctly done, but writer is. The swt, writer, volume. Writer is not done correctly, but volume is. I close all editors and collapse the tree between each try. Works on Windows XP and linux-motif
Moving to SWT. Seems to be a Linux-GTk bug since it works under Windows/XP and Linux Motif.
Chrix to investigate and advise
*** Bug 30335 has been marked as a duplicate of this bug. ***
The problem is not limited to class files. From Bug 30335, Dirk said: "We are calling setSelection(selection, true) at StructuredViewer."
Still an issue in 20030205 (m5 candidate load). Note in this load the Package Explorer view no longer automatically positions, you must request such a positioning either via alt-shift-s or Navigate->Show In. When you do request a "Show In" the Package Explorer view does not position on the file. Same problem in the Navigator view. GTK only.
This appears to be working in 20030206. Christophe, is this be design or accident?
I am seeing this behavior in 200302061700 on Win2k with JDK 1.4.0 as well.
In reference to comment #7. What you are seeing is new functionality introduced for R2.1 M5. Please see bug 30002 for more details. I am quite confident the behaviour you are seeing has nothing to do with this bug, which was gtk specific.
Eclipse 200302211557 It is not working again. RH 8.0, gtk 2.0.2
Can't reproduce on my machine with RC1 - and appears to be working again for Andrew. Jared, is it still a problem for you with RC1?
If the tree node containing the file has already been expanded, the node will be revealed. However, the following will still yield failure in the 20030221 build: 1. Click the "Collapse All" button in the package explorer. 2. Select a type in the outline view for a Java editor and select Navigate->Show In->Package Explorer 3. You can see the project containing the file expand in the package explorer, but the tree does not scroll to reveal the file.
*** Bug 34482 has been marked as a duplicate of this bug. ***
*** Bug 34485 has been marked as a duplicate of this bug. ***
*** Bug 25618 has been marked as a duplicate of this bug. ***
Christophe, this is being reported quite a bit. Increasing the priority to P2.
*** Bug 34707 has been marked as a duplicate of this bug. ***
Approved for RC3 by Veronika.
Approved by Mike for RC3.
Fixed version v>20030312
Eclipse I20030318 RH 8.0 If I have the package explorer synchronized with my editors then the positioning is correct. However, if I do not have the package explorer synchronized, and then I decide to synchronize using button on package explorer, it does not correctly position to the active file. Subsequent file switching is fine. Likewise if the package explorer is not synchronized, and I select 'show in' via Navigator->Show in, the package explorer does not correctly position.
The classI was using was org.eclipse.ui.workbench/EditorWorkbook. It appears to happen when the package expands to a large list.
*** Bug 34085 has been marked as a duplicate of this bug. ***
Note. To reproduce case described in comment 20 GTK gtk_tree_view_expand_row is not synchronous when the depth is > 1. It is executed after the gtk_tree_viewscroll_to_cell, which is synchronous. Flushing the events is one way to fix it, but this could lead to other problems. public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("PR"); final Tree tree = new Tree (shell, SWT.BORDER); tree.setSize (100, 100); shell.setSize (200, 200); final TreeItem[] items = new TreeItem[100]; items[0] = new TreeItem(tree, 0); items[0].setText("elt"+0); int n = 50; for (int i = 1; i < n; i++) { items[i] = new TreeItem(items[i-1], 0); items[i].setText("child"+i); } for (int i = n; i < items.length; i++) { items[i] = new TreeItem(tree, 0); items[i].setText("elt "+i); } Button button = new Button(shell, SWT.PUSH); button.setBounds(120,0,50,20); button.setText("show"); button.addListener(SWT.Selection, new Listener() { public void handleEvent(Event e) { tree.showItem(items[45]); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
this defect is still not fixed in the 3.0 stream! still the behavior like described in comment 20!
*** Bug 65043 has been marked as a duplicate of this bug. ***
NOTE: This is a problem in GTK that we are unable to work around right now. Other GTK C applications have exactly the same problem. I agree that it is serious but there may be nothing we can do.
I filed this bug against GtkTreeView to get their opinion: http://bugzilla.gnome.org/show_bug.cgi?id=144059
*** Bug 65158 has been marked as a duplicate of this bug. ***
*** Bug 57782 has been marked as a duplicate of this bug. ***
If we can't work around this, we should file a bug against GTK and/or close this bug report.
As it turns out, this annoying bug was fixed as a side effect of the change for bug 89665! I am marking this bug as WORKSFORME. Please re-open if this problem still exists in builds since 3.1M6. However, the example code that Chris gives in comment #23 still fails, as does the code in the linked GTK+ bug report. That example does not set the selection, and so the scrolling fails. Since all of the duplicates of this bug are about the package explorer and resource navigator, I will close this bug and file a new one about Chris' case.
Please provide a reference the bug you are openning as per comment #31
I opened bug 92176 about the expand+scroll case.
book keeping