In Kubuntu 14.04 (KDE 4.13.0), I use imwheel 1.0.0pre12-9 to map the extra thumb-buttons of my LogiTech M510 to some useful keystrokes for certain programs. This works fine, it will start nicely when my computer switches on and it will even survive suspend to RAM.
Problem is, imwheel often halts, when tv-browser.org pops up an automatic notification. I configured those notifications in KWin to always show on top and also enabled the focus steeling prevention. Also TVB is not the only program to kill imwheel.
If I haven't moved the mouse for a few seconds, imwheel will survive a TVB notification. If I'm actively using the mouse (scrolling/left-clicking/dragging) the moment, one of those popups appears, the extra-mappings of imwheel are defunct thereafter.
I ran imwheel from the console: no errors get displayed. The process of imwheel is still hanging around, but doesn't do anything anymore. It happens about once every hour, so I pretty much cannot rely on the thumb button currently issuing the command, I programmed it to or issuing e.g. a back in Firefox per default-configuration bypassing imwheel.
- Anybody else ever suffered this problem?
- How and where to get help on this complex scenario?
- Shall I report a bug against KWin? In launchpad or upstream at kde?
- Who is maintaining imwheel? There is only an outdated http://imwheel.sf.net from 2004
- Can you recommend a more up to date alternate software for mapping mouse-thumb-buttons to key-strokes in Kubuntu / KDE?
Thanks for your time and advice
Found more ways to kill imwheel almost reliably.
In Firefox, when I save a small download / an image to my harddrive there is an animation of the green arrow icon. If I click my thumb-button (supposed to close the current tab by Ctrl+W) within two seconds of that animation, the tab won't close and imwheel is defunct everywhere (also in other programs/windows)
After switching windows or desktops I have some fancy 3D effects enabled. If I'm too fast clicking one of the thumb-buttons right after such an animation, imwheel gets defunct to.
As a wild guess I'd say, imwheel somehow tries to deliver it's derived key-events that translated from the thumb-button-presses, to some graphic overlay, which is not a full fledged window itself and certainly not supposed to ever gain keyboard-focus.
Finally I found "imwheel --kill" to be way faster for reactivating it (instead of logging out and in again). I even mapped that to a global keyboard shortcut.
Debug shows, imwheel is ungrabbing buttons 4 to 9 and then waits eternally, never grabbing them again. Only a restart with -k can bring it back.
The easiest scenario is to send a mapped thumb button to a configured window, which is in the background and does not have the focus. Debug output shows, imwheel testing against the window which has the focus, not respecting the mouse position over the other window. None of the ordinary rules apply to this window, but I made an exclude rule at the end of ~/.imwheelrc like this:
".*" @Priority=-1000 @Exclude
matching every window.
Removing/commenting this final exclude rule solves my problem. imwheel won't crash anymore.