In the ubuntu 20.04, we found a regression on HDMI audio. We plug a
HDMI/DP monitor, the output device is the speaker in the output device
combo box, then we select the HDMI from the combo box, the output
device is switched to HDMI audio successfully, but the configuration
box is empty. This will not happen in the ubuntu 18.04, the profile
will show hdmi-stereo in this situation. So I think this is a
regression.
When problem happens, I could see the errors from log:
Gvc: DEBUG: Matching profile for 'output:analog-stereo' is '(null)'
Gvc: DEBUG: Matching profile for 'output:analog-stereo' is '(null)'
Gvc: DEBUG: Matching profile for 'output:analog-stereo' is '(null)'
Through debugging, I found the cc_profile_combo_box_set_device() is
called too early. In the ubuntu 18.04, this function is called after
pulseaudio changes the active_profile, but in the ubuntu 20.04, it is
called ahead of pulseaudio changes the active_profile.
To fix it, add a signal callback function, after pulseaudio changes
the active_profile, this callback function will be called, then call
cc_profile_combo_box_set_device().
Signed-off-by: Hui Wang <hui.wang@canonical.com>
This adds a widget called `CcKeyboardShortcutRow`, sub-classing
`GtkListBoxRow`, to handle a shortcut row. This makes the implementation
a bit tidier, rather than handling it all in `CcKeyboardPanel`, and
allows the widgets that compose the row to be laid out in xml.
This is a prerequisite for moving the shortcuts to a new dialog.
This commit includes all the changes that seem to be necessary for
CcKeyboardItem to be used for dealing with multiple keybindings, without
(yet) changing the user interface to expose this.
The `primary_combo` and `binding` fields of `CcKeyboardItem` are
removed, in favor of the existing `key_combos`. No combination is
"primary", since all of them can now be seen and changed equally.
We treat `CcKeyboardItem.key_combos` as a set, that a combo can be added
to or removed from. Though it continues to be represented as a `GList`,
instead of a `GHashTable`, to preserve ordering.
A lot of the keyboard panel code relied on the assumption that only one
combo can be set for each setting, so this required a variety of
miscellaneous changes.
We don't need to track them much specifically, as we delegate pad
button mapping UI on GNOME Shell. It is however possible to have
tablets with 0 to N pads (upper bound within sanity = 2), so we
must at least reflect that in the "Map Buttons..." button visibility.
This distinction is most important for the combination of EKR plus
Cintiq 27QHD, as this is a pad-less tablet, for which we wouldn't
usually show the "Map buttons..." action.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/415
This puts stylus/pad tracking on 2 separate levels. The CcWacomPanel
will look for styli, and treat them as "device leaders", adding a
CcWacomPage for them.
The CcWacomPage will then track the related pad, and update the
"Map buttons..." action visibility according to it.
This simplifies tablet page creation (eg. have it completed in one
step), and decouples the device grouping logic from CcWacomPanel,
which will be useful in future commits.
Commit f1893b8e8 (color: Connect signals with g_signal_connect_object
in swapped form) changed the connect call to use G_CONNECT_SWAPPED, but
it did not change the order of the arguments for the
gcm_prefs_device_changed_cb function.
Fixes: #1082
on some systems, private types of settings app are not resolved.
Error building template class 'CcApplicationsPanel' for
an instance of type 'CcApplicationsPanel':
Invalid object type 'CcToggleRow'
to fix this issue, ensure private types used by the template
We already had the machanism to show/hide the button based on the number
of camera devices detected. We were just not checking for that at
startup.
Fixes#1087
