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 3. Actual Results: the step is too big Expected Results: it should be smaller and more precise
Confirmed. It used to be like 5%, now it's 15% making it completely useless on a touchpad (you cannot "scroll" precisely there)
I am using KDE 4.9.97 and mouseover kmix and scrolling does nothing. I would have hope it would volume up/down ...
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%.
Same here, gentoo kde-4.10RC3
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.
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.
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%
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.
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; }
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.
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 http://commits.kde.org/kmix/207fa53763d83e8031be622c9006e41b97195d48
*** Bug 314577 has been marked as a duplicate of this bug. ***
*** Bug 315173 has been marked as a duplicate of this bug. ***
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.
*** Bug 314543 has been marked as a duplicate of this bug. ***
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
*** Bug 317024 has been marked as a duplicate of this bug. ***
*** Bug 316546 has been marked as a duplicate of this bug. ***
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.
The patch from #10 doesn't seem to fix the issue. The volume still changes by 15% points.
Confirmed. The problem still exists in 4.10.2. Kubuntu 13.04 x86.
*** Bug 319810 has been marked as a duplicate of this bug. ***
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!
*** This bug has been marked as a duplicate of bug 316546 ***
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.
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.
*** Bug 324454 has been marked as a duplicate of this bug. ***
Workaround. Insert the following in the [Global]-section in kmixrc VolumePercentageStep=1.6666
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 touchpads. Related: bug 341536 REVIEW: 121725 M +23 -6 gui/kmixdockwidget.cpp M +1 -0 gui/kmixdockwidget.h http://commits.kde.org/kmix/e318bedab3022b2972f0fe9699529afa75d68372