It’s possible for `gdk_cursor_new_for_display()` to return `NULL`. It’s
OK to pass `NULL` to `gdk_window_set_cursor()`, but not OK to then unref
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When clicking away from the applications panel you can see:
(gnome-control-center:95304): GLib-CRITICAL **: 09:12:52.941: g_hash_table_unref: assertion 'hash_table != NULL' failed
A duplicatend and translated string could be passed to gettext another
time. If that string can be translated, then a static string would be
returned rather than the const one, causing an invalid free.
Fixes: #1149
(cherry picked from commit e80b4b5f58)
In the shortcut editor, the "Replace" button is shown instead of "Set"
or "Add" when there is a collision. But this executes the same code as
"Set", so when adding a shortcut, it doesn't actually work.
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>
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.
