So we don't have to do the property tracking here...

We'll animate notifications popping up with another system soon enough,
instead. The idea here is that instead of carefully animating the Y
position of the notificationWidget when a notification updates, we
simply animate the height of the new actor inside the notification.
This will fix some of the awkward updates where instead of the
notification content expanding, we see the buttons or action area
pushed off the edge of the screen...

Animations that happen as a result of adding something new to the
notification or expanding it should be done by tweeing the new actors
in inside the notification.

Use a series of nested BoxLayouts, Bins, and more instead of an StTable
and a custom ShellGenericContainer, and hacky style classes.

This also removes the customContent parameter in favor of subclasses
setting the child of this._bodyBin instead.

We lose a few of the fancy features like showing the first part of
the body, ellipsized, next the banner when it will fit, and other
layout logic. But since the layout of notifications is changing
substantially anyways, I don't feel too bad...

As it's unused.

This sufficiently complicates the code, and won't fit in the
new design.

Now the only resident notification is a chat notification. The convenient
thing about this special-case behavior is that there's already special-case
code for it and the shell, and we always know that a chat notification will
always be 1:1 with its chat source.

They're not really an API that has caught on, and not really one
we want to support, either.

Nothing in the system actually has a standard system tray icon anymore,
so this hack isn't necessary.

This can be done with another app, like Empathy or Chat.

Users aren't usually the best at obeying the rules, and systems can
deal with hotplug without ejecting first.

https://bugzilla.gnome.org/show_bug.cgi?id=719857

Remove the networking stuff from the message tray section.

The 0x0 dummyCursor works well when the menu pops up directly underneath
the pointer (e.g. when triggered by right-clicking the titlebar) or by
keyboard, but not when triggered by the menu button - the menu does not
point to the center of the button's bottom edge, and unless the user
keeps holding the mouse button while moving into the menu, the menu will
be dismissed immediately on button release.
Address these issues by using the button geometry to overlay the window
button with an appropriately sized actor that acts as a proper sourceActor,
to make the window menu behavior consistent with other shell menus.

https://bugzilla.gnome.org/show_bug.cgi?id=731058

Having the full geometry of the menu's source button (if any) will
allow us to address several misbehaviors of window menus, so use
that instead of show_menu().

https://bugzilla.gnome.org/show_bug.cgi?id=731058

When the pointer leaves the notification area, we queue a timeout to
hide the notification after a little while. If the user is hovering over
a notification and clicks the X button to close the notification, we will
destroy the notification, which causes a "pointer left" event on the
notification area. This queues a timeout which erroneously fires after
the next notification in the queue shows up.

The code and state machine are too complex to properly make sure this
timeout doesn't fire when there is no notification up next, so instead
just clear it when showing a notification to make sure that any
previously queued timeout doesn't apply to us.

https://bugzilla.gnome.org/show_bug.cgi?id=731118

https://bugzilla.gnome.org/show_bug.cgi?id=731118

Otherwise, we won't mark the pointer as hovering on the notification.

https://bugzilla.gnome.org/show_bug.cgi?id=731118

The actual GMenu dependency was removed a while ago, so stop adding
it to the GIR includes.

Rework the way we re-exec the shell on OpenBSD so that it does not only
work the first time it is re-exec'd.
Plug a small leak in the __linux__ case while here.

https://bugzilla.gnome.org/show_bug.cgi?id=727763

We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.

https://bugzilla.gnome.org/show_bug.cgi?id=703833

We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.

https://bugzilla.gnome.org/show_bug.cgi?id=703833

Ting-Wei Lan authored Apr 25, 2014 and Florian Müllner committed May 28, 2014

It is only an internal implementation detail, and it also causes build problem
when NetworkManager is disabled.

https://bugzilla.gnome.org/show_bug.cgi?id=726460

The annotation has been deprecated in favor of (nullable) and/or
(optional).

Modal dialogs prevent the parent from being closed in "normal mode",
so it makes sense to not allow it in the overview either.

https://bugzilla.gnome.org/show_bug.cgi?id=729886

They are no longer used, kill them.