After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 685295 - Transition from login screen to desktop isn't right
Transition from login screen to desktop isn't right
Status: RESOLVED DUPLICATE of bug 682429
Product: gnome-shell
Classification: Core
Component: login-screen
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-10-02 14:07 UTC by Allan Day
Modified: 2013-04-17 17:01 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8



Description Allan Day 2012-10-02 14:07:43 UTC
The current transition has the login view shrink down to the center of the screen, revealing the desktop below it. This is better than having no animation at all, but isn't quite what was designed:

http://youtu.be/BFo0s2wnyj4?t=36s

Here you can see that the login screen slides up, to reveal the desktop maximising to fill the space behind.
Comment 1 Jakub Steiner 2012-10-02 22:31:19 UTC
I have updated the transition mockup in the meantime as the system grey texture is usually on the lowest "level" in the z-order:

http://jimmac.fedorapeople.org/gnome3/login-gray-fadein.webm
Comment 2 Matthias Clasen 2012-10-10 03:24:25 UTC
Also note that the animated transition from unlock to desktop gets confused with dual monitors - both screens appear to shrink down and fly in opposite directions. 

(See https://live.gnome.org/Boston2012/Multimonitor )
Comment 3 Stéphane Démurget 2012-10-26 13:27:50 UTC
I'd like to give it a try. Allan, Jakub: what is the expected behavior on multihead since the unlocking UI is displayed on the screen where the user rolled the curtain up?
Comment 4 Jakub Steiner 2012-10-26 14:21:31 UTC
(In reply to comment #3)
> I'd like to give it a try. Allan, Jakub: what is the expected behavior on
> multihead since the unlocking UI is displayed on the screen where the user
> rolled the curtain up?

The ideal scenario would involve more work indeed. It relates to how the curtain rolls up right now. I don't quite like how it unrolls on all screens (being different resolution and slapping empty rectangles around and all). We've been discussing this, but I can't find the relevant bug right now. 

Instead of uncovering all screens, the curtain should only lift on the screen where interaction happens (and the login/unlock dialog possible on any screen, not just the primary). Primary should be used when Esc was used to raise it though.

Once the authorization is successful, the natural transition for all displays other than the authorization one is to lift the curtain to get the working session.
Comment 5 Florian Müllner 2012-10-26 14:40:29 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I'd like to give it a try. Allan, Jakub: what is the expected behavior on
> > multihead since the unlocking UI is displayed on the screen where the user
> > rolled the curtain up?
> 
> The ideal scenario would involve more work indeed. It relates to how the
> curtain rolls up right now. I don't quite like how it unrolls on all screens
> (being different resolution and slapping empty rectangles around and all).
> We've been discussing this, but I can't find the relevant bug right now.

Bug 685300 I presume.
Comment 6 Allan Day 2012-10-29 10:56:40 UTC
(In reply to comment #1)
> I have updated the transition mockup in the meantime as the system grey texture
> is usually on the lowest "level" in the z-order:
> 
> http://jimmac.fedorapeople.org/gnome3/login-gray-fadein.webm

Are we able to implement this? Perhaps someone could comment on the feasibility of the design?
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-10-29 13:29:15 UTC
(In reply to comment #6)
> (In reply to comment #1)
> > I have updated the transition mockup in the meantime as the system grey texture
> > is usually on the lowest "level" in the z-order:
> > 
> > http://jimmac.fedorapeople.org/gnome3/login-gray-fadein.webm
> 
> Are we able to implement this? Perhaps someone could comment on the feasibility
> of the design?

It wouldn't be nearly as smooth, and there would be a large gap before starting the shell but after logging in if we did this.

I'm also not sure how this works with multiple monitors.
Comment 8 Jakub Steiner 2012-10-29 14:08:25 UTC
> I'm also not sure how this works with multiple monitors.

Described in comment #4
Comment 9 Ray Strode [halfline] 2012-11-01 19:31:59 UTC
we seem to have a duplicate bug here.  Some notes on how to potentially implement this in bug 682429

*** This bug has been marked as a duplicate of bug 682429 ***
Comment 10 Jakub Steiner 2013-04-17 17:01:03 UTC
We have discussed this with ryan and garrett extensively during LGM and we've come up with a transition that avoids the jarring zoom and keeps the system layer from being composited over the desktop.

I've mocked it up and provided a small infographic about the different layers in the following video:

http://www.youtube.com/watch?v=Dcr0ke2UeaI

The slide happens only on the primary display. Secondary displays continue to fade like they do now, to avoid the complexity of the physical layout.