Community
Participate
Working Groups
Bad things happen on both GTK and Windows. Not quite sure if all these steps are needed but I'm including everything. On GTK, do this: 1) Get a fresh GTK Eclipse (eclipse-SDK-I20030326-linux-gtk.zip) 2) Open Perspective->CVS Repositry Exploring - connect to dev.eclipse.org - expand HEAD - multi-select org.eclipse.swt, org.eclipse.swt.gtk, org.eclipse.swt.examples - check out as project 3) Open Perspective->Other...->Java Perspective 4) Window->New Window 5) expand org.eclipse.swt.gtk 6) expand os.linux.x86 7) multi-select the 3 lib files (libswt-gnome-gtk-XXX ...) 8) Export->File system->Next 9) ***BUG! - no libraries are selected in the export dialog 10) select the 3 lib files from 7) in the dialog 11) export them into your jre/bin (probably doesn't matter the directory) 12 ***BUG! - wrong window comes to the front On Motif do this: ... steps in progress (stay tuned)
Do the steps on Windows and Motif and the wrong window comes to the front after step 8).
Doesn't happen in the Navigator.
This is a JDT problem. In their ImportActionGroup class, they create the import and export actions. But they are using the old deprecated constructors. They should use the constructor where you past in the actual window (you already known the window via part.getSite().getWorkbenchWindow()).
If the ImportResourcesAction would call workbench.getActiveWorkbenchWindow() in the run method instead of the constructor the this would fix the problem for other clients still using the deprecated API as well.
*** Bug 36734 has been marked as a duplicate of this bug. ***
Simon, any comments regarding comment #4
Sorry about that...I was going to comment on this but things got busy with 2.1 release! At the moment, there is some discussion about removing a bunch of deprecated API for the 3.0 release (to ease the maintenance). This would be one of them. If the decision is to keep this old API, I will seriously consider making the change you requested. The down side is it spreads code to support deprecated API into other parts of the class.
The group now calls the constructors taking an IWorkbenchWindow. Moving to Platform UI to consider the comment #4 for the deprecated methods.
We're not removing deprecated API for 3.0, so I'll make the suggested change. Should scan for other uses of getActiveWorkbenchWindow(), which we never should have provided in the first place <g>.
Should fix ExportResourcesAction as well.
deffering, if you feel this is important for R3.0 please re-open.
MVM, I would like multiple windows to work better in 3.0. They did not work well in 2.1.x so I don't think there is a regression.
Steve, do you have some concrete cases that are problematic?
I don't have a repeatable case but it's still happening. Seems more likely when a full build is happening but I can't be sure.
Version: 3.0.0 Build id: 200405290105 Just happened to me again, this time expanding a package tree in a packages view order to see the classes. First it took about 3 centuries, then it brought the wrong window to the front. Very annoying. There were lots of classes in the package. It seems that that the wrong window comes to the front when an operation takes a long time. I'm pretty sure I've never seen it happen otherwise.
Dirk, does the package explorer kick off any jobs, or report progress in any other way, when a package is expanded? What happens when the Java Model needs to do some work to get the list?
The package explorer doesn't kick off any job to get the children of a package. We call fragment.getCompilationUnits() & fragment.getNonJavaResources () or fragment.getClassFiles() & fragment.getNonJavaResources() depending on whether the package contains binaries or sources. Both don't take a progress monitor so we don't report any progress either. CC Philippe to answer Nicks questions regarding the Java Model.
I'm sometimes seeing the wrong window get activated, usually when doing an override and update from the sync view. In this case, though, it's not another workbench window that gets activated, it's another app's window! Steve, any idea how this could be possible?
I think this can happen when Windows tries to activate a shell that is disabled. When a shell is disabled, it is frozen on the desktop. I will attempt to construct a simple example.
Steve, do you still see this?
I stopped seeing it before 3.0 and during most of the M's up until the last few weeks and then it started happening again. I know that Team made some changes around "trying to find the right parent for a dialog" (I don't have the PR or the details). I have a simple example somewhere of how to make Windows do this. Not sure how to proceed.
Which dialogs do you typically see it with? A few weeks ago, we changed the heuristic in the code which determines which parent a dialog gets, for some of the error dialogs.
It's not the dialog, it a whole other Eclipse shell. I'll add to this bug report if I see it again and include the build number.
Reassigning bugs in component areas that are changing ownership.
Apparently we ask this question every spring... Steve, do you still see this? At any rate, moving prio to P3 since this is so stale.
I didn't try the steps again but, yes, the wrong window comes to the front even more using the debugger. I believe I entered a separate bug report for that.
Now, the wrong window is coming to the front in the compare view. It's happening to Boris now too.
I entered bug 166483, not sure if it is a duplicate, or a separate issue.
I'm going to assume that the fix in bug #166483 addressed this issue. Please reopen if you think this is a bad assumption. *** This bug has been marked as a duplicate of bug 166483 ***
Go ahead and mark it any way you want. It has been happening since 2003 and I have long since given up hope that it will be fixed. It doesn't have steps, doesn't happen every time etc. and I have been unable to spend the time to get to the bottom of it myself due to other work.
