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 666127 - Newly-paired Bluetooth devices don't show up in Gnome panel menu
Newly-paired Bluetooth devices don't show up in Gnome panel menu
Status: RESOLVED FIXED
Product: gnome-bluetooth
Classification: Core
Component: applet
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-bluetooth-general-maint@gnome.bugs
gnome-bluetooth-general-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2011-12-13 20:59 UTC by James
Modified: 2012-01-18 14:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description James 2011-12-13 20:59:40 UTC
As per the summary: when a new device, in this case my headset, is paired (starting via "Set up a New Device" in the panel menu), it connects and works, but no new device entry shows up in the menu.

The device appears upon restarting Gnome-shell.

(Removed devices disappear from the menu upon removal as they should.)
Comment 1 Giovanni Campagna 2011-12-13 23:31:56 UTC
There seems to be a bug in the emission of devices-changed signal from libgnome-bluetooth-applet, as calling updateDevices manually works.
Reassigning...
Comment 2 Bastien Nocera 2011-12-16 16:34:33 UTC
Can you reproduce the problem using the "fallback" applet?

(You can get it working like so:
http://www.hadess.net/2011/04/want-to-debug-old-status-icon-applet.html)
Comment 3 James 2011-12-16 17:03:01 UTC
(In reply to comment #2)
> Can you reproduce the problem using the "fallback" applet?

(I used the symbolic link trick.) Yes, it still happens in that case: newly-attached headset doesn't show up in the menu. Output from running it:


$ g-applet-bt 
(g-applet-bt:16951): Bluetooth-DEBUG: adding killswitch idx 3 state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
Agent registration failed: Already Exists
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:16951): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
** Message: has_config_widget 00:1A:7D:20:21:43 HSP
** Message: has_config_widget 00:1A:7D:20:21:43 Handsfree


I take it that the last two messages indicate it has received some notification of the new device? (The MACs are the headset's.) Running it again, the device appears. Output this time:


$ g-applet-bt 
(g-applet-bt:17019): Bluetooth-DEBUG: adding killswitch idx 3 state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
Agent registration failed: Already Exists
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitch 3 is KILLSWITCH_STATE_UNBLOCKED
(g-applet-bt:17019): Bluetooth-DEBUG: killswitches state KILLSWITCH_STATE_UNBLOCKED


Another note: from the fallback applet, in the second run, attempting to "Disconnect" the device via the menu doesn't work reliably. Sometimes it fails to disconnect; others times it actually does (as seen in Gnome Control Centre), but the applet's menu does not reflect this.
Comment 4 James 2011-12-16 18:02:29 UTC
(To clarify: bluetooth-applet doesn't sync correctly when the connection state of a device changes.)
Comment 5 Bastien Nocera 2012-01-18 14:09:40 UTC
commit 56ad8665a257befa0d4cee4a532e483c7733dc75
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Jan 18 14:05:17 2012 +0000

    applet: Fix new pairings not appearing in menus
    
    As documented now, the GtkTreeModelFilter that we use to
    filter per-adapter devices lacks the ability to tell us
    about row-changed signals (amongst others).
    
    So just monitor those signals on the child-model of the filtered
    model, and check whether those rows are in our view to trigger
    the "devices-changed" signal.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=666127

commit ad88f437dd5c1a627b64feca8ce9b0d2db01b9f2
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Jan 18 13:59:28 2012 +0000

    lib: Add doc about GtkTreeModelFilter shortcomings
    
    Such as the possible lack of row-inserted/row-deleted/row-changed
    signals, and the necessity to monitor the child-model of that filter.