GNOME Bugzilla – Bug 678221
Shell does not appear until all startup applications are loaded
Last modified: 2013-03-13 13:15:12 UTC
When you choose your user and enter a password, you see this smooth transition from GDM to the desktop, which is nice. But, nothing actually happens, all you see is the desktop... then, suddenly, every thing just pops up. And this is not right.
- The few seconds that the user waits for the top panel to appear makes the whole "nice transition" pointless. Because, it doesn't take you to a working desktop, it takes you to a wallaper. And you'll wait there.
- The same seconds also gives the impression of a slow, heavy shell. Which is not the case.
- The shell should _not_ wait for programs that are not part of it until they initialize to start.
: If you have, for example, Dropbox, Sparkleshare, Mailnag... as startup applications, the shell would not appear until _after_ they all start. Only then, the all appear toghether like good buddies.
Thanks, and sorry for the comical title. :P
Which distribution is this about?
I'm not sure it's distro-specific. But I'm on Arch Linux.
Also, I forgot to mention what I think is the right way.
Load GDM, enter password, load the shell and its extensions, let it appear while other startup applications load. Just don't load everything in the background and display it at once.
I don't think this behavior is really intended, i.e. the Shell probably does not wait for all apps to be ready. Rather, it takes time to start because all processes are launched concurrently, and they fight for resources. Fixing this would require starting the Shell with a higher priority (which systemd could probably do when it handles session startup), or waiting for the Shell to be ready before starting apps (but that would slow down starting the apps, and you probably need them if you run them at startup).
But if they are fighting over resources, at least I should get: apps>shell>apps behavior once in a while, no? Or even shell>apps. All I get is apps>shell.
Hi Reda, would it be reasonable to consider this a duplicate of bug #645756?
Yes, I think so. Plus, you have better input. Please feel free to mark this a dup. :)
*** This bug has been marked as a duplicate of bug 645756 ***