Merge lp:~sacridex/ubuntu/precise/unity-greeter/purple-background-on-startup-fix into lp:ubuntu/precise/unity-greeter
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~sacridex/ubuntu/precise/unity-greeter/purple-background-on-startup-fix |
| Merge into: | lp:ubuntu/precise/unity-greeter |
| Diff against target: |
49 lines (+7/-3) 3 files modified
src/background.vala (+1/-0) src/main-window.vala (+5/-2) src/user-list.vala (+1/-1) |
| To merge this branch: | bzr merge lp:~sacridex/ubuntu/precise/unity-greeter/purple-background-on-startup-fix |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Terry | 2012-04-24 | Needs Fixing on 2012-05-29 | |
| Bryce Harrington | patch | Approve on 2012-04-24 | |
| Robert Ancell | 2012-04-24 | Pending | |
| Ubuntu branches | 2012-04-19 | Pending | |
|
Review via email:
|
|||
Description of the Change
I think there is no synchronisation issue.
But there is too much stuff to be done between the initial background color and the actual background image is drawn.
There are 2 things that take longer than 0.2 seconds: launching Canberra and playing the startup sound takes about 0.26 seconds and LightDM.get_layout () (line 81 in menubar.vala) takes about 0.20 seconds.
So there was about a half second gap between those two backgrounds, unfotunately a ~0.1 second gap still remains.
The fact that the standard purple image is loaded at all, is a problem caused by appending the *other user to the user_list(which is the first user added, so the purple image is drawn) and then removing it later(which triggers a background redraw of the actual image).
But still, unity-greeter will fade from the initial background color to the actual background image, because the fade time is set and i am not able to disable it and reset it later. :(
But in my opinion that is no problem, the fade in actually looks nice.
I disabled canberra and loaded the LightDM standard layout earlier. Also i made the Guest background image relying on the Gsettings value of LightDM User.
Unfortunately there is no more background image for the *other user, otherwise this image would be drawn(as described above).
===============
Another UPDATE:
I reverted all the KeyFile parts.
| Philipp (sacridex) wrote : | # |
Dont be surprised by the Undecided/Invalid bug status it is linked to. Thats the wrong one actually. The bug is referred to unity-greeter not lightdm, thats why. If you click on the link to it, you will see.
| Michael Terry (mterry) wrote : | # |
We don't want to move back to keyfiles for the configuration. We used to have that, but switched to gsettings to make it easier for derivatives to change values. (i.e. we're optimizing ease-of-changes for derivatives, not the user)
| Bryce Harrington (bryce) wrote : | # |
I don't know vala very well so can't comment on the quality of the code, but the patch looks clean now.
| Michael Terry (mterry) wrote : | # |
Just coming back to this. Why is default_
| Philipp (sacridex) wrote : | # |
Because the guest account has no image.
If a user has no background(which I think is impossible, but who knows), the default_background is used(background
So the guest account has a background image after all, and not just the background color.
But thinking about it now, it would be a better solution, not to put the "*other" user into the user_list at first(user-
| Michael Terry (mterry) wrote : | # |
But it is possible and common for users not to have a set background (either they use a private image that the greeter doesn't have access to or encrypted home directories or the like).
So we need to do the same logic for them that we do for the *other user.
| Sebastien Bacher (seb128) wrote : | # |
ideally the merge request should be retargetted to an active serie as well, either precise-proposed or quantal


The diff is showing some unfinished merge work in background.vala.