There's only two uses of the parameter left, which can easily be added as a
separate line below. Since it's really a private interface meant for the
indicators, make it private as well so external users are less likely to
use it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
To align the arrows, we need to allocate panel buttons the full
height of the tray. Fix up all of the panel buttons to support this,
and align the arrows in the middle.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Swap out the implementation of SystemIndicator with a dummy,
and build the aggregate menu. At the same time, remove the
poweroff and login screen menus, as those were fake aggregate
menus beforehand.
We lose some flexibility as we lose session-mode-based menu
layout, but as each component of the aggregate menu is supposed
to be "smart" in response to updating itself when session
state changes, I believe it's better than a declarative model.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We can't silently replace the old behavior of separate status
icons into a new system. Replace SystemStatusButton with a new
SystemIndicator class which will allow for the flexibility we
need. For now, make it a subclass of Button so that it mostly
feels the same, but we'll soon be swapping it out with a dummy
implementation that the aggregate menu will use.
I think the code cleanup here is worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
This code is too complicated to keep, and the last straw came after the
fixed width menu in the aggregate menu design.
This will break some existing popup menus that rely on the fixed width,
but this will soon be replaced with the aggregate menu. We'll also soon
clean this up further by replacing PopupBaseMenuItem's custom layout code
with an StBoxLayout.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
Showing the new message at full size marks an abrubt change and looks
bad. Instead, gradually animate from 0px to full natural height.
Includes hacks to workaround flickering scrollbars while the animation
is in progress.
https://bugzilla.gnome.org/show_bug.cgi?id=687660
If that fails (which only ever happens in initial-setup mode, which
has no unlock or login dialog), we don't want to go ahead with
whatever we were doing.
https://bugzilla.gnome.org/show_bug.cgi?id=701848
If we don't remove the animation, we might leave a pending call
to _lockScreenShown() which would confuse our state tracking into
thinking we're active when we're not.
https://bugzilla.gnome.org/show_bug.cgi?id=700901
Using a signal handlers causes us to depend on connection order, but
we need the message tray code to run last, so it can notice that
notifications are destroyed when hiding the boxpointer and skip
the broken animation.
https://bugzilla.gnome.org/show_bug.cgi?id=686855
When we shift workspaces to create a blank one for a window or
application, all of the window actors are shifted down. However, some
of these window actors are transient windows attached to a main window.
When these windows are moved to a different workspace, the main window
is moved along with it. When the main window is moved, these windows
are also moved. This creates a double move of the windows.
This double movement leads to unexpected results where workspaces are
collapsed and windows are in incorrect positions.
This patch prevents movement of these transient windows, only grabbing
the main (ancestor) windows to move to a different workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=705174
