Bugzilla – Full Text Bug Listing
| Summary: | [WorkbenchLauncher] splash screen blocks the switch workspace dialog and creates illusion of hung application | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Stuart Mackey <smackey> | ||||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aniefer, billy.biggs, CWNL-Eclipse-Bugs, desarmo, emoffatt, gsmith, jastein, matt.casson, paul.melching, pwebster, rwatts, Silenio_Quarti, snorthov, wmitsuda | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.4 M7 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 161569 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Stuart Mackey
What window manager are you using? Gnome / Metacity Fedora Core 3 $ uname -a Linux 2.6.11-1.35_FC3smp #1 SMP Mon Jun 13 01:17:35 EDT 2005 i686 i686 i386 GNU/Linux I'm having trouble replicating this myself exactly. Maybe what *really* happened is that I accidentally clicked on the splashscreen beneath the select workspace dialog which brought it forward and at that point hid enough of the 'select workspace' dialog to that it was no longer obvious the dialog was back there. So I'm tempted to think it's user error now. But, would it be possible to make the select workspace dialog modal in such a way that it can never be 'hidden' behind the splashscreen even if the user accidentally clicks on part of the splashscreen? Unfortunately, the splash screen is opened from a separate process, so it's hard to coordinate a relationship between them. metacity also tries to do some focus stealing prevention which can affect the stacking order. I'm not sure what else we can do that's reasonable. Boris, this is the classic problem of having the workspace launcher maybe be a real dialog for the splash screen window. In recent builds, the Workspace Launcher is opened as a top-level shell, so it should show up in the task bar. (In 3.1, it might not appear on the task bar.) Which build were you using? it has always appeared in the task bar on Linux, the issue here is the stacking order. On Paul's Linux box with GNOME, using 3.1, the Workspace Launcher does not appear in the task bar. With a recent build, it does appear. Short of fixing the root cause, we could do one of the following: - Make the dialog bigger (taller, wider) than the splash screen. Splash screens, according to the spec, "should be approximately 500x330 pixels in size". - Use Shell.forceActive() to bring the dialog to the front (does this work on Linux)? Any opinions, or other/better ideas? *** Bug 162234 has been marked as a duplicate of this bug. *** This can happen on Windows too. I'm afraid we cannot solve this unless the splash screen is shown from within Eclipse using SWT. Reassigning bugs to reflect changes in ownership. The splash is now wrappered via SWT but this happens long after the workspace dialog is opened. Still, it may be possible for us to do something here. I'll investigate. We see this frequently on Windows and have several defects opened against our product about this. Kristin: I'd be curious to know what versions of Eclipse you product is delivered on. We're on 3.2.2 I've been working at this off and on for some time now. I have the ability to parent the shell off of the splash screen which manages to fix this issue but causes more of them on Windows (and perhaps linux - I haven't checked there but I suspect it'd be problematic there as well). The issue on Windows is that the splash shell is created with the shell style bits for WS_EX_TOOLWINDOW set. This means that the shell is created without having an entry in either the task bar or in the alt-tab list. When we then parent the chooser shell off of it we are now in the state where you can no longer alt-tab to the chooser which, IMO, is far far worse than having it appear under the splash. Silenio: would it be possible for you to reset this style bit in the special constructor you gave us using ModifyStyleEx()? I believe it is possible to change the style on the fly, but there was a reason to remove the window from the task bar. Modifing the style will bring that bug back. Andrew do remember why? Can we avoid setting WS_EX_TOOLWINDOW and fix the original problem some other way? I believe it has to do with the icon and title of the window in the case where java is launched in a separate process from the launcher. The launcher.dll has no icon in it because it may be shared accross products. I don't know if I'm imagining this, but I think that the icon and title where ok once the workspace chooser dialog came up by virtue of being set by swt (?) If this is the case, then modifying the style at that point will be ok. *** Bug 120648 has been marked as a duplicate of this bug. *** (In reply to comment #18) > I believe it has to do with the icon and title of the window in the case where > java is launched in a separate process from the launcher. The launcher.dll has > no icon in it because it may be shared accross products. > > I don't know if I'm imagining this, but I think that the icon and title where > ok once the workspace chooser dialog came up by virtue of being set by swt (?) > > If this is the case, then modifying the style at that point will be ok. > Okay, assuming we're all right here, could we have a method on win32 at least to switch the style for the shell? It's too late for API but this doesn't necessarily make sense for API anyway. Silenio? (Removing the target milestone until we're sure we can move forward on this) Kim, can't the workspace switcher dialog be created as a child of the splash screen? That way it will stay in front. I'm sure you've tried this right? (In reply to comment #22) > Kim, can't the workspace switcher dialog be created as a child of the splash > screen? That way it will stay in front. I'm sure you've tried this right? > Sure, but as I mentioned above, this is problematic on Windows because the splash is made with the WS_EX_TOOLWINDOW bit. I can parent off of it but then I dont get anything in the taskbar. What I was looking for was a way to remove that style bit (causing the splash to have a taskbar entry) after we're up to the point where we're opening the chooser dialog. We released code that makes the splash screen appear in the task list when a dialog shell is created. There is no new API. Please parent the workspace prompter from the splash screen and try it out. (In reply to comment #24) > We released code that makes the splash screen appear in the task list when a > dialog shell is created. There is no new API. Please parent the workspace > prompter from the splash screen and try it out. > I've got your latest code checked out and I'm stepping through it (with changes at our end to parent the shell off the splash) but it doesn't appear to do anything. There still isn't an entry in the taskbar for the new eclipse instance after calling OS.SetWindowLong(hwndParent, OS.GWL_EXSTYLE, style| OS.WX_EX_APPWINDOW). Funny, this worked on Silenio's machine when we started Eclipse within Eclipse. We've never tested it on a single Eclipse. Perhaps this doesn't work on Silenio's machine either, just like it doesn't work on yours? (In reply to comment #26) > Funny, this worked on Silenio's machine when we started Eclipse within Eclipse. > We've never tested it on a single Eclipse. Perhaps this doesn't work on > Silenio's machine either, just like it doesn't work on yours? > I was self-hosting as well. Created attachment 94066 [details]
Dumb patch. Nowhere near final.
Created attachment 94269 [details]
A better patch.
Eric, could you give this patch a try on Vista if you have a moment? You'll need to set your workspace location to @noDefault I've tested this patch on Windows (XP and Vista), GTK, and OS X. I'm going to check it in now and verify on next build that it works on AIX/Motif/etc. This has been behaving nicely for awhile now. I'm going to mark this as verified in I20080429-0100. If anyone objects, please reopen. |