Community
Participate
Working Groups
Many people observe the problem with hanging splash screens. Also, loading Eclipse can take a lot of time depending on the workspace. It would be good have a progress bar to indicate whether it's really hanging or still booting. Of course, some status info should be displayed as well (like which plugin is being loaded, etc.). Please have a look at the Gimp splash screen to see what I mean.
Side note: If the GIMP didn't come installed with your OS, get it at www.gimp.org.
Re-assigning to McQ as this is part of the eclipse.exe.
We will not be adding a progress bar to the splash screen. That is far beyond the scope of the eclipse.exe program (for example, it would require *portable* inter-process communication between the C code in eclipse.exe and the Java code in Eclipse). All of the "lot of time" which you are seeing is being spent within the Java code. The best solution to this particular problem would be to build an SWT based "loading progress" dialog early in the core startup, with appropriate progress messages displayed. Unfortunately, given the "heavy weight" process used to get SWT loaded (i.e. it's a plugin so it needs the plugin loading support to be already active -- compare with javax.swing.* which is included in rt.jar!), there's no easy way for the core to build this dialog. I believe the best answer to this problem is just to ensure that it doesn't take a long time to start up. This would require a more asynchronous mechanism for getting the platform going. So that, for example, the first workbench window could appear while some plugins are still being loaded. Moving back to Core for potential future progress dialog support...
This is a good idea that we will not be able to get to for 2.0. If there is interest in the community to provide this feature send a message to the developer's mailing list.
Reopen for investigation
*** Bug 96068 has been marked as a duplicate of this bug. ***
N20050522 Currently, the splash screen is only shown for a short time, and is then replaced with the progress monitor. If communicating with the executable is too expensive, why don't we do the following: - show the normal splash-screen first - when the required plug-ins are loaded: show an SWT-based splash-screen with a progress bar overlaying the original splash. The second splash should look as closely as possible like the original splash.
raising severity to 'normal' as I think shipping 3.1 with the current solution does not look good.
marking this bug as 3.2 with regards to improving on what is in 3.1
(In reply to comment #7) > N20050522 > > Currently, the splash screen is only shown for a short time, and is then > replaced with the progress monitor. > > If communicating with the executable is too expensive, why don't we do the > following: > - show the normal splash-screen first > - when the required plug-ins are loaded: show an SWT-based splash-screen with a > progress bar overlaying the original splash. The second splash should look as > closely as possible like the original splash. I'd like to vote for this approach.
We did not do this for 3.1 (showing the progress dialog on top of the splash screen) because it seemed to brittle to try and open the progress dialog at the exact location of the splash screen. For one, the splash screen is shown at different locations on different platforms. Furthermore, it is not clear if you can guess the location correctly in multi-monitor setups. All in all too much risk so close to the 3.1 release.
By the way, why there is a native splash anyway?
Just wanted to note that the progress bar in 3.1-RC1 is much better than the one I saw when posting comment 7. While the suggested approach would still be cool (I know the PR has not been closed yet), I cannot say any more that the current solution 'does not look good'.
There is another approach that I believe is far cleaner than the current 3.1M7RC1 version has. What if launching application would get a handle of the splashscreen as a Shell or Composite widget (or just a well-defined section of the splashscreen) and could draw upon it as it saw fit. This would easily solve the issue of detecting proper monitor and position of the splashscreen plus allow applications define themselves what dthey would prefer to show on this splashscreen. As an example - a login or workspace picking dialog could be drawn straight on the splash screen or splashscreen shell could be used as a parent shell for those dialogs, which would easily solve the issue with those dialogs getting hidden behind splashscreen in some situations. Of course application implementation should be careful to take into account few extreme situations - like no splashscreen (the reference to splash is null?) or different splash dimensions than expected, but none of these should be unsolvable issues imho. What do You think?
I don't know but RC1 with the progress dialog "feels" much slower starting up than previous versions without the dialog. I haven't gone back to previous versions and timed it so it may be my imagination but it definitely seems slower to get to the point where the workbench window opens.
(In reply to comment #15) > I don't know but RC1 with the progress dialog "feels" much slower starting up > than previous versions without the dialog. I haven't gone back to previous > versions and timed it so it may be my imagination but it definitely seems slower > to get to the point where the workbench window opens. I also noticed a "gray box" effect for this progress dialog on Windows. And it is really annoying that you can't move it around the screen.
Created attachment 22858 [details] progress bar bug in RC2 I have also noticed that the new progress bar will be "broken" in RC2, if one click on the splash screen (see attachment). The RC1 version was better.
Created attachment 25637 [details] patch to org.eclipse.ui.workbench
Created attachment 25638 [details] patch to org.eclipse.sdk
Patch from comment #19 applied and changes released for next N and I builds.
Workbench patch released to HEAD
Removed dependency on bug 102856.
Tested on Linux GTK. The font color needs to be changed.
Opened bug 105981 for the foreground color issue.
Marking as fixed. Please open new bugzillas for any problems with the new progress bar, or if you have specific requirements for Eclipse-based products that cannot be met using the current support. There are three new properties that can be set in the products extension point to configure size/position/color of the progress bar and the messages being displayed. The three new properties are described in IProductConstants.java (org.eclipse.ui.workbench).
Applied patch from comment#19 (with color modification) to org.eclipse.platform/plugin.xml.
Verified on Windows XP.
Verified on Linux and Mac too. Marking as verified.
*** Bug 56167 has been marked as a duplicate of this bug. ***
*** Bug 59026 has been marked as a duplicate of this bug. ***
