diff options
author | Ratchanan Srirattanamet <ratchanan@ubports.com> | 2022-06-22 00:44:00 +0700 |
---|---|---|
committer | Ratchanan Srirattanamet <ratchanan@ubports.com> | 2022-06-22 00:46:15 +0700 |
commit | b3adf1f4e9c406a7e3416259a9fa989f330f4942 (patch) | |
tree | 2f8e2ce3b443fd95338e2bb9628055503523e2b7 /Jenkinsfile | |
parent | 1e922c24bd09ee216fb7ef9093ffecbd59d1670d (diff) | |
download | ayatana-indicator-bluetooth-b3adf1f4e9c406a7e3416259a9fa989f330f4942.tar.gz ayatana-indicator-bluetooth-b3adf1f4e9c406a7e3416259a9fa989f330f4942.tar.bz2 ayatana-indicator-bluetooth-b3adf1f4e9c406a7e3416259a9fa989f330f4942.zip |
src/*.vala: make the switch item & action QMenuModel compatible
QMenuModel, inheritting code from GTK, will consider the menu item not
"activatable" if the item's "target" [1] doesn't match the corresponding
action's parameter. Since we take a boolean as action's parameter (and
we can't change action's parameter easily since it's semi-public), we
instead have to pass "target".
Taking a page from the slider menu items, pass "true" as the target
will make QMenuModel considers the item activatable and reflect the
right state.
And while we're at it, restore the ability to use g_action_change_state
to change the state. This allows the clients that still support
Canonical's indicator (e.g. Lomiri) to not have to distinguish between
that and Ayatana's. This, again, is taken from how the slider menu items
work.
[1] i.e. the parameter to pass when activating the action. See
https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI#Attributes
Related: https://github.com/AyatanaIndicators/qmenumodel/issues/21
Diffstat (limited to 'Jenkinsfile')
0 files changed, 0 insertions, 0 deletions