| Summary: | KStatusNotifierItem capture mouse wheel events three times. kmix and amarok get 3x volume change | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Enrico Tagliavini <enrico.tagliavini> |
| Component: | notifications | Assignee: | Marco Martin <notmart> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adam, adaptee, cfeck, daniel.eckl, flateric, hein, honyczek, kfunk, maxy, mig21, nalvarez, obuolis1, plasma-bugs, rdieter, retratserif, skystis, travneff |
| Priority: | NOR | ||
| Version: | 4.10.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=317024 | ||
| Latest Commit: | http://commits.kde.org/kde-runtime/d8089973bd83b7297ee67765b88ad56094a36adb | Version Fixed In: | 4.11.4 |
| Sentry Crash Report: | |||
| Attachments: |
kDebug output for kmix for a single wheel movement
Suppressed redundant MouseEventListener signals |
||
Created attachment 77956 [details]
kDebug output for kmix for a single wheel movement
I just installed Fedora 18 on another PC. I updated to KDE 4.10.2 [which comes with normal fedora updates] and I have exactly the same problem. *** This bug has been marked as a duplicate of bug 313579 *** I take it back, even with the fix from bug #313579 , I still seem to be seeing 15% jumps. odd. (In reply to comment #4) > I take it back, even with the fix from bug #313579 , I still seem to be > seeing 15% jumps. odd. I've done some hack around kmix to get the inc value printet. It is correct, it correspond to an increment in the volume of 5%, as expected. But it is captured 3 times in a row for a single wheel step. So, clearly the title of this report (about 3X mouse events) is accurate. Interestingly, I was hoping that setting systemsettings->Input devices->mouse->advanced(tab) mouse wheel scrolls by : ... to values other than 3 may help here, but alas, it did not. *** Bug 313579 has been marked as a duplicate of this bug. *** Bug 313579 has the patch for this bug. It's also older and has more votes. This bug should be a duplicate of it, not vice versa. Adam, the patch in bug #313579 doesn't help (not for me anyway). hard-coding a step of 5% + this bug (processed events 3 times) still means a 15% jump per mouse scroll. :( Rex, I see. This is getting confusing. Maybe the bug was in KStatusNotifierItem all along, not kmix. I'm not sure that these are duplicate bugs, though. Created attachment 80465 [details]
Suppressed redundant MouseEventListener signals
I made a patch for plasma runtime (4.10.3) which fixes this issue.
The problem is caused by MouseEventListener item emitting multiple wheelMoved() signals for the same wheel event (once for every child item).
Attached patch suppresses redundant mouse signals.
I don't know if the original behavior of MouseEventListener was required in other parts of plasma desktop, so I might have introduced some side effects. The kmix problem is definitely solved though.
(In reply to comment #11) > I made a patch for plasma runtime (4.10.3) which fixes this issue. Thank you very much for that. Not an easy spot at all. I think you can also submit the patch the the KDE reviewboard. This might be a way to have it merged quicker (In reply to comment #11) > Created attachment 80465 [details] > Suppressed redundant MouseEventListener signals > > I made a patch for plasma runtime (4.10.3) which fixes this issue. > > The problem is caused by MouseEventListener item emitting multiple > wheelMoved() signals for the same wheel event (once for every child item). > Attached patch suppresses redundant mouse signals. > > I don't know if the original behavior of MouseEventListener was required in > other parts of plasma desktop, so I might have introduced some side effects. > The kmix problem is definitely solved though. I'm testing this under KDE 4.10.4 on gentoo. I applied your patch to plasma-runtime. Now both kmix and amarok are working as expected. I can see no side effects at first glance. Please consider this patch to be integrated. The problem is not critical, but very annoying :). Thank you again I can also vouche the proposed patch here works as advertised (thanks) Please add the patch to https://git.reviewboard.kde.org/ so that Plasma developers can review it for inclusion. Seems fixed for me with KDE 4.10.5 at Fedora 19 x64. true, fedora's kde-runtime-4.10.5-3+ builds include the proposed patch from comment #11 naur, I've discussed and reviewed this patch together with Marco Martin as I was fixing other bugs in MouseEventListener, and we'd like to merge it upstream. Could you please re-submit it via ReviewBoard, so we get a proper real name for the submission? Could you please check comment #18? To get your commit into KDE repositories, we need proper attribution. I've since explained the problem to Nicolás Alvarez and he has written a fix for this independently, without having seen the original patch, i.e. we should have a committable cleanroom implementation now. (In reply to comment #20) > I've since explained the problem to Nicolás Alvarez and he has written a fix > for this independently, without having seen the original patch, i.e. we > should have a committable cleanroom implementation now. So, is this patch commited already? Can we close this bug? If not, could please add a link to the reviewboard? Thanks, Unfortunately that effort stalled because we realized the bug is actually "unfixable" in the sense that the fix avoids this bug, but causes others, because it's fundamentally based on comparing and discarding mouse events by their pointer values, which aren't good-enough unique ids because Qt can sometimes allocate new events on the stack in the exact same location, making them indistinguishable. QEvents sadly have no monotonic timestamp or similar. We could commit it as a lesser evil of sorts, but basically MouseEventListener is fundamentally broken. Hi Eike. It is since that patch was attached to this bug that I apply it to my KDE build. In short it is about 6 month I'm using it. 2 days ago I've adapted the patch to KDE 4.11.2 and built it. I run this Desktop no less then 10 hours per day (weekend included) since it is both my work laptop and my personal laptop. In 6 months I never had a glitch with mouse events related to the system tray. While I understand when you say this fix introduces other problems due to address collision, but in practise this seems to be unlikely. This is just my personal experience so YMMV. That said I think it is very worth including the fix to mitigate the issue for KDE 4.x and accept the idea it is broken. A proper solution can be developed for KDE 5. In the meantime users are not affected by the issue. Keep in mind, while this is not critical, it is extremely annoying and affects almost all mouse wheel + system tray users. Thank you :) Well the patch compares the pointers received, which could be argued that are rarely the same between calls if it's not an error. Anyway, I don't get how is that the MouseEventListener is installed three times, is that a bug in plasma-widget or am I missing something else? The event objects are usually created as local variables on the stack. They will have the same address whenever the same code path is followed. It's not rare or unlikely, in my tests every click had a mouse click event at the same address in memory. MouseEventListener is not installed three times. It handles events for all its children, and the item hierarchy in the tray happens to have three items there. Git commit d8089973bd83b7297ee67765b88ad56094a36adb by Nicolás Alvarez. Committed on 06/10/2013 at 19:35. Pushed by nalvarez into branch 'KDE/4.11'. MouseEventListener: Don't process event from children multiple times. If an event passed through multiple visually-overlapping children of MouseEventListener, the event filter was processing the event every time. For example, this caused problems for the KMix icon in the tray, which would trigger volume changes three times for every mouse wheel event. M +5 -0 plasma/declarativeimports/qtextracomponents/mouseeventlistener.cpp http://commits.kde.org/kde-runtime/d8089973bd83b7297ee67765b88ad56094a36adb Thank you very very much! The only regression i noticed is that now scrolling step in add widgets dialog is three times smaller, other than that, its fine |
When using the mouse wheel to change volume from a tray icon on kmix or amarok I get 3 times the volume change I expect. For kmix the default is 5%, I get 15%, for amarok I get 12%. I think the problem is KStatusNotifierItem capture 3 events and not just one. Example of amarok debu log (I just paste what happens when using the wheel on the icon, for a single movement of the wheel, a.k.a 15 degrees, if more is needed ask :) ). amarok: BEGIN: void Amarok::MediaPlayer2Player::volumeChanged(int) amarok: MPRIS2: Queueing up a PropertiesChanged signal amarok: END__: void Amarok::MediaPlayer2Player::volumeChanged(int) [Took: 0s] amarok: BEGIN: void Amarok::MediaPlayer2Player::volumeChanged(int) amarok: END__: void Amarok::MediaPlayer2Player::volumeChanged(int) [Took: 0s] amarok: BEGIN: void Amarok::MediaPlayer2Player::volumeChanged(int) amarok: END__: void Amarok::MediaPlayer2Player::volumeChanged(int) [Took: 0s] amarok: BEGIN: void DBusAbstractAdaptor::_m_emitPropertiesChanged() amarok: END__: void DBusAbstractAdaptor::_m_emitPropertiesChanged() [Took: 0s] or kmix enabling kDebug() (will attach it in a second, it is long) The mouse wheel works as expected when used on kmix sliders or on the volume control inside amarok. Reproducible: Always Steps to Reproduce: 1. start amarok --debug 2. use the mouse wheel over the amarok icon in the system tray and look at the output In alternative 1. enabled kmix kDebug(): start kdebugdialog and check kmix, apply 2. quit kmix (eg killall kmix) 3. start kmix again from the command line 4. use the mouse wheel with mouse over the kmix icon, save the log and check the event is captured 3 times