| Summary: | Open workspace dialog opens behind splash screen | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tod Creasey <Tod_Creasey> | ||||
| Component: | UI | Assignee: | Andrew Eidsness <eclipse> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P2 | CC: | jeem, jeffmcaffer, n.a.edgar | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.0 M8 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Tod Creasey
Moving to Nick, whose I believe provided this dialog. Any possibility of addressing this this afternoon, to get it in for the rebuild? Flagging as a major usability problem. It works OK for me on Windows 2000 -- the dialog appears on top of the splash. Although the splash is still up, so if I click on it, it obscures the dialog. We should probably take down the splash while the dialog is up, then bring the splash back until the workbench is fully up. Jeff, is it possible to bring the splash back up after endSplash has been called? Created attachment 8617 [details]
patch
I've created a patch that opens the dialog as "always on top".
This might also become a usablity problem if the dialog opens and obscures a
window that the user needs to determine where they want to put their workspace.
What we really need is for the dialog to go on top as soon as it opens (so the
user knows that its there), but then allows other windows to be activated on
top of it.
hey, we (uhhh, you) can splash as many times as you like. Once you have called end splash, we are out of the business but you can call eclipse.exe and put the splash back up and then tear it down again. You can even put up a different splash. Well, we can't hardwire a reference to eclipse.exe since the app wasn't necessarily launched with that executable (or any for that matter). I see that InternalPlatform.getSplashHandler() does some funky context and service stuff, searching for a service whose name property is "splashscreen". Could we make this a real service that knows how to both bring down the splash and bring it up again, rather than just being a Runnable that brings it down? Also, I'm curious as to why it ungets the service reference before returning the result of getting it. I'd expect that whatever it returned would potentially be invalid after ungetting the service. This service stuff is somewhat bogus. it should actually just be spec'ing a filter and using a normal service tracker. That code was likely done very early in our OSGi lives. The service approach is not meant to be general. It is our internal way of communicating between levels without exposing API. The splash is actualy put up in main() way before OSGi is started etc. Main also creates a runnable that can tear down the splash. This is passed along to OSGi (via EclipseStarter.run ()) when it is started. In there it gets registered as a service so that it is available to the runtime when needed. All you really need to do is exec eclipse.exe to put up the splash and remember the OS process. Then you kill the process when you want to take the splash down. As for using eclipse.exe, we recommend that people supply their own exe but implement it by calling eclipse.exe. Note, the suggestion to put up a different splash after the prompt is problematic since products will want to supply that as well. Then we have two splashes to manage. Just thought of... If the problem is showing the user something while loading the workspace, how about showing a progress dialog? The sequence would then be splash up, splash down, workspace prompt up, prompt down, progress up, restore UI, progress down, work This would probably work better. Should try it to see how it plays. *** Bug 55126 has been marked as a duplicate of this bug. *** The main problem has been addressed for M8. I opened bug 56167 to revisit the splash/prompt/progress interaction in M9. Verified on Windows XP with Build id: 200403250800. Verified on Windows XP Build id: 200403260800. |