The lock screen shortcut doesn't update when its value is changed in dconf

[Andrew Hayzen]

Hi

Description: Ubuntu 12.04 LTS
Release: 12.04
unity:
  Installed: 5.12-0ubuntu1.1
  Candidate: 5.12-0ubuntu1.1
  Version table:
 *** 5.12-0ubuntu1.1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     5.10.0-0ubuntu6 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

indicator-session:
  Installed: 0.3.96-0ubuntu1
  Candidate: 0.3.96-0ubuntu1
  Version table:
 *** 0.3.96-0ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

What happened:
- With the 'Lock screen' shortcut set to Ctrl+Alt+L the indicator displays Alt+L as the shortcut.

What I expected to happen:
- I expected for the indicator to display the correct shortcut.

Notes:
- I have attached a screenshot displaying this issue.

Many thanks

Andy

[Bilal Akhtar (bilalakhtar)]

Did you switch that keymap to something before changing it back to Ctrl+Alt+L? That could've caused it. Either way, it's a bug.

[Andrew Hayzen (ahayzen)]

Hi Bilal

I think I did at some point and then changed it back.

So yes this is probably why the error has occurred, hope it can be fixed at some point :)

Thanks,

Andy

[Charles Kerr (charlesk)]

I'm not able to reproduce this in indicator-session 12.10.0.

In that version, the shortcut value comes directly from org.gnome.settings-daemon.plugins.media-keys.screensaver.

[Omer Akram (om26er)]

Andrew, is that still an issue in Ubuntu 12.10 ?

[Andrew Hayzen (ahayzen)]

Omer, should the change be instant in the indicator?

I have managed to change it from Ctrl+Alt+L to Alt+L but now it won't change back (the indicator displays Alt+L whereas the system settings say Ctrl+Alt+L)!

Does it take a session restart for the indicator to update or should it update in real time?

Thanks,

Andy

[Charles Kerr (charlesk)]

This is happening because of the way DBusMenu implements its menuitems.

GtkMenuItem is a GtkBin, and gtk's menuitem.c adds a single child, a GtkAccelLabel (which is a private Gtk class). DBusMenu wants the single child to be a container, so it reparents that GtkAccelLabel into an hbox and sets the hbox as the single child. (see genericmenuitem.c's set_label()).

Unfortunately, this breaks Gtk's gtkmenuitem.c's gtk_menu_item_sync_action_properties() function, which only updates the GtkAccelLabel's properties if the GtkAccelLabel is still the direct child of the menuitem.

It looks like there's some precedent in gtkmenuitem.c to look harder for the Accel Label if the menuitem'c child is a container. This is what's done in gtk_menu_item_accel_width_foreach() as a part of determining the menuitem's preferred width for gtk_menu_item_get_preferred_width().

Maybe a similar patch would be accepted upstream for gtk_menu_item_sync_action_properties(). I haven't tested such a patch, but I think it would resolve this bug.

[Charles Kerr (charlesk)]

This is fixed in indicator-session 13.10 as a result of its internal changes from dbusmenu to gmenu.