Bug 313579 - kde 4.10 rc3: kmix applet in systemtray mousewheel volume step is too ridiculously big (~10% at the scroll)
Summary: kde 4.10 rc3: kmix applet in systemtray mousewheel volume step is too ridicul...
Status: RESOLVED DUPLICATE of bug 316546
Alias: None
Product: kmix
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Esken
: 314543 314577 315173 317024 (view as bug list)
Depends on:
Reported: 2013-01-20 17:13 UTC by Simonas
Modified: 2015-01-20 21:11 UTC (History)
23 users (show)

See Also:
Latest Commit:
Version Fixed In:

Patch for branch KDE 4.10 (963 bytes, patch)
2013-02-04 20:51 UTC, Christian Esken
kDebug output for kmix (6.78 KB, text/plain)
2013-03-11 10:13 UTC, Enrico Tagliavini

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2013-01-20 17:13:59 UTC
previously it was like 3-4% on one mousewheel. and its not too slow with mousewheel.

Reproducible: Always

Steps to Reproduce:
1.hover on kmix icon
2.use mousewheel to volume up/down
Actual Results:  
the step is too big

Expected Results:  
it should be smaller and more precise
Comment 1 Kai Uwe Broulik 2013-01-23 02:09:45 UTC
Confirmed. It used to be like 5%, now it's 15% making it completely useless on a touchpad (you cannot "scroll" precisely there)
Comment 2 Mathieu Jobin 2013-01-23 02:11:20 UTC
I am using KDE 4.9.97 and mouseover kmix and scrolling does nothing.
I would have hope it would volume up/down
Comment 3 Richard Feciskanin 2013-01-23 13:22:15 UTC
I can confirm this bug (two different PCs). 
Scroll volume step is now 3 times bigger than value in settings. I had to set smaller value in kmixrc, I am now using parameter VolumePercentageStep=2, which make volume step 6%.
Comment 4 ml 2013-01-25 07:19:56 UTC
Same here, gentoo kde-4.10RC3
Comment 5 Christian Esken 2013-01-28 21:38:38 UTC
Cannot reproduce that. And the code has not changed since quite some time. The code is like that:

     int inc = vol.volumeSpan() / Mixer::VOLUME_STEP_DIVISOR;
    if ( inc < 1 ) inc = 1;

VOLUME_STEP_DIVISOR is 20 as default, so if for example the control has volumes 0 - 200 , I will use  inc = 201/20 = 10.  And 10 is about 5% of 201.

I also cannot reproduce Mathieus issue, and it should not happen as I always increment by at least 1.
Comment 6 Kai Uwe Broulik 2013-01-28 21:41:14 UTC
I also checked the code and wondered how it could have broken but here it did. Here it always in/decreases by 15% when using the mousewheel and 5 when using function keys. The mousehweel scroll setting (how many pages are scrolled, which is 3, so I thought maybe it's there because 3*5=15) has no effect.
Comment 7 Colin J Thomson 2013-01-28 22:08:52 UTC
I am seeing this also 4.9.98/F18. However it only happens here if I scroll on the system tray icon.
If you Click on the icon and scroll the volume slider from the pop up box the steps are how they where ~ 5%
Comment 8 Christian Esken 2013-02-04 20:15:35 UTC
Thanks everybody for all the your insightful input.

I have now read the Qt docs again. It is clearer now than in the past about specifying the magical number "120", see http://doc.qt.digia.com/main-snapshot/qwheelevent.html#delta :

 > Returns the distance that the wheel is rotated, in eighths of a degree. [...]
 > Most mouse types work in steps of 15 degrees, in which case the delta value is a multiple of 120; i.e., 120 units * 1/8 = 15 degrees.
 > However, some mice have finer-resolution wheels and send delta values that are less than 120 units (less than 15 degrees).

So what does this mean:

a) The 0% issue (Mathieus issue):
So, if delta is less than 120, I will finally end with a "change value" of cv = 0:
  long int cv = inc * (delta / 120 );  // delta/120 == 0  (for all delta <120). Thus cv == 0

b) The 15% issue (original bug report):
If your page scroll is 3, then the KMix behavior is correct. 3*5% = 15%.

There would be one universal "solution". Ignore all "delta" values, because a "page step" does not seem to make sense in the context of KMix. Thus always head for a predefined value. Though this has the risk to break optimal use of alternative input devices (Touchpad, Track Pad, Trackball), I will consider to go this way.
Comment 9 Christian Esken 2013-02-04 20:48:52 UTC
Yes, this looks like an old TODO. I added the following to the Slider class some time ago:

 * TOOD This should go to the Volume class, so we can use it anywhere,
 * like mouse wheel, OSD, Keyboard Shortcuts
long MDWSlider::calculateStepIncrement ( Volume&vol, bool decrease )
  	long inc = vol.volumeSpan() / Mixer::VOLUME_STEP_DIVISOR;
	if ( inc == 0 )	inc = 1;
	if ( decrease ) inc *= -1;
	return inc;
Comment 10 Christian Esken 2013-02-04 20:51:45 UTC
Created attachment 76912 [details]
Patch for branch KDE 4.10

The patch can be applied to KDE 4.10 branch. In trunk I will do the real/full solution.
Comment 11 Christian Esken 2013-02-04 22:31:08 UTC
Git commit 207fa53763d83e8031be622c9006e41b97195d48 by Christian Esken.
Committed on 04/02/2013 at 23:30.
Pushed by esken into branch 'master'.

Use a fixed volume step of n% instead of honoring mouse delta (which is more appropriate for text documents). Also Mouse Wheel now only affects EITHER playback OR capture
Related: bug 300783

M  +1    -1    apps/kmix.cpp
M  +0    -1    core/mixdevice.cpp
M  +14   -14   core/mixer.cpp
M  +0    -3    core/mixer.h
M  +29   -8    core/volume.cpp
M  +6    -1    core/volume.h
M  +9    -9    gui/kmixdockwidget.cpp
M  +9    -7    gui/ksmallslider.cpp
M  +67   -46   gui/mdwslider.cpp
M  +1    -3    gui/mdwslider.h

Comment 12 Jekyll Wu 2013-02-07 18:10:14 UTC
*** Bug 314577 has been marked as a duplicate of this bug. ***
Comment 13 Jekyll Wu 2013-02-15 07:11:30 UTC
*** Bug 315173 has been marked as a duplicate of this bug. ***
Comment 14 Christian Esken 2013-02-22 23:58:43 UTC
Resolved for KDE 4.11.
There is also a certain chance that the whole code gets copied back to the 4.10 branch. But don't take it for granted.
Comment 15 Christian Esken 2013-02-23 00:09:34 UTC
*** Bug 314543 has been marked as a duplicate of this bug. ***
Comment 16 Enrico Tagliavini 2013-03-11 10:13:27 UTC
Created attachment 77944 [details]
kDebug output for kmix

Hi there, I have more or less the same problem here (mouse wheel makes 15% volume change from 4.10), but I'm not sure this is the same issue. From comment #8 it seems if you set page scroll to 1, you should get 5%, and this is not what happens it seems.

I enabled kDebug() and I can see that the function trayWheelEvent is called 3 times, so the volume is increased/decreased 3 times, hence 15%. But again I have the page scroll set to 1, so this seems a separate bug isn't it? Also this happens for all Qt application it seems: using the mouse wheel over the amarok icon in the systray has a 12% volume increase, but using the wheel on the volume control inside the amarok application just works as expected and does 1% volume change with page scroll set to 1 (3% if set to 3). The 12% if fixed, not matter the page scroll value. In VLC using the scroll wheel on the video area now change the volume more then before (again 12.5% it seems), using the wheel on the volume bar does increase/descrease the volume by 5% as expected.

I think this is related/triggered by KDE since it happens from KDE 4.10 update... but can be a Qt bug. Any help is appreciated (this issue is very annoying)

attached is the kDebug() for a single mouse wheel movement
Comment 17 Rex Dieter 2013-04-17 17:02:56 UTC
*** Bug 317024 has been marked as a duplicate of this bug. ***
Comment 18 Rex Dieter 2013-04-17 17:04:05 UTC
*** Bug 316546 has been marked as a duplicate of this bug. ***
Comment 19 Felix Geyer 2013-04-17 18:03:09 UTC
Christian, why didn't you push your fix from #10 or a backport of the full fix to the 4.10 branch?
This is a big usability bug after all.
Comment 20 Felix Geyer 2013-04-20 15:36:31 UTC
The patch from #10 doesn't seem to fix the issue. The volume still changes by 15% points.
Comment 21 Pyroman 2013-05-07 19:48:01 UTC
Confirmed. The problem still exists in 4.10.2.

Kubuntu 13.04 x86.
Comment 22 Jekyll Wu 2013-05-14 04:38:33 UTC
*** Bug 319810 has been marked as a duplicate of this bug. ***
Comment 23 missive 2013-05-18 03:18:00 UTC
When it says "Patch for branch KDE 4.10" does that mean the patch has been applied to 4.10? Should 4.10.2 be working properly?

If so, please re-open this bug. Thanks!
Comment 24 Jekyll Wu 2013-05-18 04:58:15 UTC

*** This bug has been marked as a duplicate of bug 316546 ***
Comment 25 Adam Porter 2013-06-01 21:57:24 UTC
It appears that there is a bug in KStatusNotifierItem causing mouse wheel events to be processed 3 times, listed as bug 316546.  I don't know if these are two separate bugs or if patching kmix was just the wrong way to fix it.  Either way, since this report has a patch that fixes perhaps a different bug, I don't think these should be marked as duplicates.
Comment 26 Jacopo Martellini 2013-06-18 19:10:10 UTC
i don't know which is the bug that causes this behavior but that patch didn't fix the problem on my pc. so i ended up using "long cv = inc/3;" and now it seems ok.
Comment 27 Jekyll Wu 2013-09-03 13:45:55 UTC
*** Bug 324454 has been marked as a duplicate of this bug. ***
Comment 28 Søren Holm 2013-11-04 13:15:24 UTC
Workaround. Insert the following in the [Global]-section in kmixrc

Comment 29 Christian Esken 2015-01-20 21:11:33 UTC
Git commit e318bedab3022b2972f0fe9699529afa75d68372 by Christian Esken.
Committed on 20/01/2015 at 21:09.
Pushed by esken into branch 'master'.

Fix kmix tray icon scrolling for high-precision scroll devices like
Related: bug 341536
REVIEW: 121725

M  +23   -6    gui/kmixdockwidget.cpp
M  +1    -0    gui/kmixdockwidget.h