In order to build a better transition animation from the lock screen, we
need to split the world into layers, as per this reference:
https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/system-layers2.png
Everything that pertains to the user's session is in the "session group",
which includes the window group, overview, message tray (for now),
keyboard, OSDs, menus, etc.
For implementation sake, we did not match this mockup exactly. The new layers
look like this, from top to bottom:
* Stage
* Magnifier (clones the uiGroup)
* uiGroup
* overlayGroup
* menuGroup
* panelGroup
* screenShieldGroup
* sessionGroup
* top_window_group
* other boxes (trayBox, keyboardBox, etc.)
* other groups (osdGroup, switcherPopupGroup, etc.)
* overviewGroup
* window_group
* systemGroup
The "session startup" animation now only zooms in the sessionGroup.
The panel is now outside the session, as it needs to sit above the screen
shield. This also means that it's not zoomed in as part of startup. I think
this is OK.
This also means that the lightboxes that the screen shield uses to fade out
the screen have to go in a new group, above the panel. This is known as the
overlayGroup, which has no relation to the old mutter group of the same name.
We also change the screen shield to put the lockDialogGroup in the system
group, and put the lockScreenGroup in the screenShieldGroup, which means
that the layer stacking is correct. Note that we don't hide the session
group in the lock screen yet, which is something I want to do.
Since not a lot of items need to be in the uiGroup anymore, we've removed
the Main.uiGroup fallback; others should use sessionGroup instead, when
appropriate.
This helps take cruft out of the uiGroup, and ensures that components remain
stacked properly on top of each other. In the future, we'll use this group
to ensure that grabs are ordered properly, as well.
If the notification is destroyed between an allocate and the redraw,
the meta_later is invoked on a destroyed object, and fails because
the clutter calls are invalid at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=722547
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
For mysterious reasons I'm not sure of myself, navigate_focus will only focus
mapped actors. So, make sure the widget is showing before navigating to it.
https://bugzilla.gnome.org/show_bug.cgi?id=709853
The methods we call in _updateState may not be reentrant, so make
sure that we never get into a situation where _updateState, through
some crazy chain of events, calls itself.
https://bugzilla.gnome.org/show_bug.cgi?id=711694
When a notification becomes expanded, it's either already shown,
or in the process of being shown. Don't set the state to SHOWING
again, which confuses our state machine.
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Otherwise, when closing the tray, we'll try to focus an actor, which will
focus the stage window, which will drop the focus from whatever window we
already had focused.
https://bugzilla.gnome.org/show_bug.cgi?id=710347
If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
NotificationDaemon doesn't pass a gicon to the Notification constructor,
because it calls .update() immediately after, so messageTray.js
calls into Source.createIcon(), which returns null and crashes.
Instead, shortcut the Notification constructor by skipping
.update() completely.
https://bugzilla.gnome.org/show_bug.cgi?id=709998
According to the designs, the notifications switch was supposed
to move from the user menu to the new message tray menu. However
so far the new system status implementation only removed the old
switch, so add it back in its new place now.
https://bugzilla.gnome.org/show_bug.cgi?id=707073
_updateState has a lot of variables that sort of gunk up the
code and make it more unreadable than need be. Clean up the logic
a lot by moving those variables into the places that they actually
matter, renaming them to remove prefixes, and remove some conditions
that are always met.
Right now the code chooses to animate based on whether or not the
notification was "removed", which is quite a sketchy subject. For
now, add an additional case so that we don't animate when we transition
to the lock screen.
