Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEAT(client): Control + mouse wheel scroll to adjust local volume in TalkingUI #6629

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

davidebeatrici
Copy link
Member

This new feature allows to change the local volume adjustment for the selected user by scrolling the mouse wheel up (increase) or down (decrease) while Control is pressed.

…TalkingUI

This new feature allows to change the local volume adjustment for the selected user by scrolling the mouse wheel up (increase) or down (decrease) while Control is pressed.
@davidebeatrici davidebeatrici force-pushed the talkingui-ctrl-scroll-local-vol-adj branch from b7f9676 to 271f727 Compare November 13, 2024 02:09
@Hartmnt
Copy link
Member

Hartmnt commented Nov 15, 2024

I will look at this in detail after the next 1.5.x release

@Hartmnt Hartmnt added the feature-request This issue or PR deals with a new feature label Dec 8, 2024
@@ -375,6 +375,7 @@ struct Settings {
bool bTalkingUI_AbbreviateChannelNames = true;
bool bTalkingUI_AbbreviateCurrentChannel = false;
bool bTalkingUI_ShowLocalListeners = false;
bool talkingUI_CtrlScrollLocalVolAdj = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the number of people never noticing this feature exists is probably higher than those who would be annoyed by this, I guess it would make sense to enable this by default.

Comment on lines +591 to +592
if (volAdjustment >= 30) {
// 30 dB is the upper limit defined for the volume slider (VolumeSliderWidgetAction.cpp).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a great reason to implement some kind of member in VolumeSliderWidgetAction that returns the min/max in case we ever want to change it again.

</widget>
</item>
<item row="5" column="0">
<widget class="QCheckBox" name="qcbCtrlScrollLocalVolAdj">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the tab order such that it includes this new element at the correct position. Should be possible to do visually using Qt-Designer.

volAdjustment -= 1;
}

user->setLocalVolumeAdjustment(VolumeAdjustment::toFactor(volAdjustment));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does set the new local volume temporarily, but it is not retained. You can test this by adjusting the volume using your method and then changing client state of the user you adjusted (e.g. deafen and immediately undeafen)

To retain the changes we need to add:

Global::get().db->setUserLocalVolume(user->qsHash, user->getLocalVolumeAdjustments());

return;
}

ClientUser *user = Global::get().mw->pmModel->getSelectedUser();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Weird" things happen, if you enable to always show your local user (or channel listeners) and use this scroll event. Mainly, it changes the local volume of yourself which has currently no effect IIRC, but can not be changed back using the "self" context menu.

Unless we plan to use self-local-volume-adjustment for something, I think you should add a check that we are not able to change the local volume of ourselves.

@@ -569,6 +571,41 @@ void TalkingUI::mousePressEvent(QMouseEvent *event) {
updateUI();
}

void TalkingUI::wheelEvent(QWheelEvent *event) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This brings me to my next consideration: Why are we only allowing this in the Talking UI? It feels like the main user list could also profit from this. Maybe I am missing something you already considered?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client feature-request This issue or PR deals with a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants