feat(AudioPanel): volume change on mouse wheel

[koffydrop]

Pull Request

Motivation

Previously you could not adjust volumes with the mouse wheel on the volume widget, despite being able to in the control center, which annoyed me to no end.
This works on inputs, outputs and, per application audio.

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring

Testing

Just regular day-to-day use.

• Tested on niri
• Tested on Hyprland
• Tested on sway
• Tested with different bar positions and density settings
• Tested at different interface scaling values
• Tested with multiple monitors (if applicable)

Screenshots / Videos

Checklist

• Code follows project style guidelines
• Self-reviewed my code
• No new warnings or errors
• Documentation or comments updated (if relevant)

Additional Notes

I just copied and adapted the code from AudioCard. Not sure if there's more that needs to be considered.

I'm also testing it on version 4.5.0 which is the one packaged in nixpkgs at the moment, but I made sure to check it does work on main with noctalia-qs.

This introduces this warning, which I'm not sure how to fix without breaking functionality.

WARN scene: QML MouseArea at @Modules/Panels/Audio/AudioPanel.qml[674:25]: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.

[ItsLemmy]

This is not quite right, the right approach would be to add a onWheel signal in NSlider and use that appropriately.
Let me know if you wanna tackle this, or I'll do it when I got some time

[koffydrop]

I'll give it shot, if I can't figure it out I'll let you know

[koffydrop]

@ItsLemmy how does this look?

I'm not sure why jumping from 4.5.0 to 4.6.8 makes the sink and source volumes not follow the volume step if it changes too fast, but application audio works as expected

[ItsLemmy]

I don't know either, all I know is PW does not like to receive a bunch of volume changes in a small time frame, as they have some quick fade implemented somewhere. That's why we usually debounce calls.

[koffydrop]

Gotcha. In that case this should be good for review, unless you prefer if I squash into a single commit

[ItsLemmy]

• Would be better to move the MouseArea to be a top-level child of the Slider root (after the handle), not inside background. When on the background the knob wont react to wheel events.

• For the Layout warning, you can try y: (parent.height - height) / 2 instead of anchors.verticalCenter:
  parent.verticalCenter.

• Would be awesome if you could also edit AudioCard to use that new feature, so we avoid keeping a separate custom implementations.

[koffydrop]

The layout warning actually goes away after moving the MouseArea to NSlider, and anchors.fill: parent now makes it work like I originally intended.
Should I still prefer using y: (parent.height - height) / 2 or remove the more manual anchor and size properties in favor of anchors.fill: parent?

[ItsLemmy]

No this was only a workaround to avoid the warning, if it's gone keep it simple with the original syntax.

[koffydrop]

I'm not sure why jumping from 4.5.0 to 4.6.8 makes the sink and source volumes not follow the volume step if it changes too fast, but application audio works as expected

I used the local*VolumeChanging variables and a timer to reset them after 100ms without wheel input, so now the text should display the correct volume before syncing to pipewire.

Also with a volume step of 1 sometimes the sliders don't register a change due to float precision, and makes it impossible to stop at certain values without closing their respective panels first. I rounded the checks to account for that, hope that's alright.

If you can think of other sliders that could use this I can look into them as well.

[koffydrop]

Testing now on 4.7.1 day-to-day, no apparent issues so far