Fix some issues reported by Bjørn Lie in bug 740906.
f3b8f0b...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
Bump version to 3.16.4
Update NEWS.
c3ac059...
by
Emmanuele Bassi <email address hidden>
st: Remove wrong indentation
GObject-Introspection started warning for wrong annotations, and
StGenericAccessible::set-current-value has a return value annotation
even if it returns nothing. This generates the warning:
Which, coupled with fatal warnings, breaks the Shell build.
9d791ac...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
dash: Ensure style for icon size computation
StIcon will skip loading the texture when its theme node is unset (which
may happen on style changes while the widget is hidden). While our size
request to compute the dash icon size will create the icon's theme node
if necessary (and of all its parents), a missing texture can still throw
off our computation.
Make sure this doesn't happen by ensuring the icon's style first, so the
texture is updated in response to StWidget::style-changed if necessary.
ae8dc11...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
dash: Revert mislead cleanup
When adjusting dash icon sizes, we compute the icon padding by subtracting
the configured icon size from the first icon actor's preferred size. To
make sure that the preferred size correctly corresponds to the current
dash icon size even while the icon is animating, we enforce the size
before the size request. For that we used to temporarily manipulate
the icon texture size directly, but commit e92d204d425 cleaned this
up to use the setIconSize() method instead.
This does not work however, as the icon actor's iconSize property will
always match the dash iconSize property, making the method a noop. So
go back to the original approach of enforcing the texture size to make
sure we always base our computations on correct values.
calendar: Disconnect all Notification signals on NotificationMessage destruction
The destroy signal handler is kept connected despite the NotificationMessage
being destroyed, which leaves dangling NotificationMessage objects that will
be mass destroyed when the Notification object these depend upon is finally
destroyed.
Depending on the amount of accumulated NotificationMessages, this may lead
to temporary freezes or other more funky issues when recursion limits are
hit.
