When there's no active input or output device, the input/output meter shouldn't
have a stream set, so call set_input_stream() with a NULL stream
(cc_volume_slider_set_stream() and cc_level_bar_set_stream() are already handling
NULL as expected) in case there's no active input or output device.
This fixes a bug where the input/output meter doesn't get updated when the active
input or output device gets unset.
When gvc gives us an active-input/output-device ID we don't know or sets the ID
to 0, that means there's no device currently active. While this seems unlikely
to be the case without the device getting removed at the same time, it can happen:
When the bluetooth profile gets changed from handset (input+output) to
headphone (output only), the input device remains available, but there's no
more active-input-device anymore.
In this case, we shouldn't leave the active entry on the device combo box as-is,
instead we should set it to NULL to indicate that no input device is set.
This fixes a bug where the input switcher is not updated when there's no
internal microphone but there's a bluetooth headset connected, and the
bluetooth profile gets switched from Handset to Headphone.
Gvc is the actual "source of truth" when it comes to the currently active input
or output device, so we should update widget visibility and the input/output
meter stream based on the information from gvc, not on changes to the combo box.
The flow when the selects a different device in the combo box now is:
"user change" -> gvc_mixer_control_change_output() -> receive
"active-output-changed" signal from gvc -> update active device and get it
using the DeviceComboBox -> set widget visibility and update stream based
on this device.
This fixes a few bugs where the stream for the input/output meter wouldn't
get updated properly on active device changes.
When we get notified of an "active-input/output-device" change by gvc, we have
to update our respective combo box to reflect that change. Obviously, this in
turn shouldn't trigger our own signal handler for changes on that combo box,
that signal handler is only meant to handle the user interacting with the combo
box.
So block our signal handlers when we update the combo box to respond to changes
from the gvc side.
This fixes a recursive call to gvc_mixer_control_change_input/output() when we
get notified about an input/output change from gvc itself.
We should only listen to "active-input-update" and "active-output-update" in
one place, and then update the combo box from there. This way we can block our
own signal handler for input/output device changes on the combo box, which
we'll do in the next commit.
- refresh the symbolic icons to sync some style changes and update the source sheet
- rename assets for the privacy subpanel's symbolic icons
- delete deprecated/unused symbolic icons
- add new icon for system panel
- add new icon for remote desktop so it isn't using displays icons
Settings shows list rows with radio buttons before the
row title. However, the alert chooser looks inconsistent
because it shows the radio buttons at the end of the list
rows.
Fix that by setting the radio buttons as prefix widgets.
With this change, Orca now reads the word
"speaker", for example: "Front Left Speaker push button"
instead of "Front Left push button".
Also, remove the a11y labels because Orca also reads
tooltips.
The output test wheel is fixed size with a size of 300px
and a margin of 60px on both sides. Decreasing each value
by 20px, makes it fit a width (and height) of 360px.
see: !1563
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
While the combo box for devices can get ellipsized labels,
the one for the profile cannot. For Bluetooth profiles
with long descriptive names, this can lead to large
minimal widths for the combo box, the row, and the panel.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Meson extracts them by itself and add them as dependencies for the target.
It means one less location to keep track of files, and a lot less boilerplate
around the meson files
For unknown reasons, GVC mixer control can sometimes signal a new
device with the same id as one that was added before. This means that
in `device_added_cb`, a duplicate entry with that id is created, in my
case with a different name. However, the last one added is valid, but
that one cannot be selected because all other logic in the sound panel
assumes the first hit in `get_iter` is valid. This breaks sound input
selection then.
The fix is easy; only add a new list entry if none with that id exists.
Previously this was problematic because the current layout is a bit
messy. The reasoning is a bit complex, but I'll try to explain below.
Basically the AdwPreferencesGroup has an integrated GtkListBox where the
rows should normally be added to it by declaring AdwPreferencesRow
subclasses as its direct children in the UI file. This is not currently
done in the sound panel and we instead have another GtkListBox as its
direct child, while the "No Devices" row is actually a AdwPreferencesRow
subclass, so we end up with two listboxes with .boxed-list style. The
problem is that we hide the "No Devices" row when there are devices
available, but the internal listbox is still there, so we still see its
shadows.
This commit just separates the "No Devices" row in a separate group so
that we are sure to hide everything correctly.
Just measure the label to make GTK not complain about allocating
children without measuring anything. Measuring all the buttons is an
overkill because we expect this widget to have the minimum size
overwritten by CSS either way.
When pressing the mute button after the volume slider is manually moved
to 0 (and so the GVS "is-muted" property is still FALSE), set the volume
to 25% instead of actually muting the stream.
Fixes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/520.
The logic inside it is a bit reworked to make it more consistent. The
mute button and the slider now only communicate directly with GVC. The
notify callbacks are now used to change the UI states.
This fixes the UI problem of the mute button being "raised" when pressed
(see https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/520).
This is useful for the next commit because the stream list will be moved
in a separate window and to do that we need an always-updated list of
the playing streams. Without this approach, we would lose all the
streams that played before the user opens the stream list window. Also,
this allows us to decuple data and UI, which is definitely not a bad
thing.
