After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 786526 - shell-tray-manager: Disconnect theme_widget signals on finalize
shell-tray-manager: Disconnect theme_widget signals on finalize
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-08-19 21:46 UTC by Florian Müllner
Modified: 2017-08-20 16:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
shell-tray-manager: Disconnect theme_widget signals on finalize (3.24 KB, patch)
2017-08-19 21:46 UTC, Florian Müllner
committed Details | Review

Description Florian Müllner 2017-08-19 21:46:31 UTC
See patch.
Comment 1 Florian Müllner 2017-08-19 21:46:39 UTC
Created attachment 357994 [details] [review]
shell-tray-manager: Disconnect theme_widget signals on finalize

The theme widget passed to shell_tray_manager_manager_screen() is simply
a means to receive style information. There is nothing which ties the two
object's life cycles together, so it is entirely possible for the tray to
be finalized with the widget still around - we shouldn't try to update the
stale object on widget style changes, so make sure we properly disconnect
the signal handler.
Comment 2 Rui Matos 2017-08-20 15:13:24 UTC
Review of attachment 357994 [details] [review]:

Since we don't actually re-set the theme widget, a simple g_signal_connect_object() would be a much simpler solution. This is fine too of course
Comment 3 Florian Müllner 2017-08-20 16:05:53 UTC
Attachment 357994 [details] pushed as b5d3c4e - shell-tray-manager: Disconnect theme_widget signals on finalize

(In reply to Rui Matos from comment #2)
> Since we don't actually re-set the theme widget, a simple
> g_signal_connect_object() would be a much simpler solution.

Thanks for the suggestion, that function completely slipped my mind.