Version: (using KDE 4.0.80) Installed from: SuSE RPMs OS: Linux A recent regression (moved from Kubuntu to OpenSUSE and at the same time upgraded from 4.0.80 to 4.0.82). Until now, the mouse wheel could be used to focus a window without altering it (not raising it (alt-tab), not moving the text input (left click), not pasting from the clipboard (middle click), and not triggering the context menu (right click)). Now the mouse wheel will scroll, but not set the focus. And I can't find anywhere to set the behaviour back.
Scrolling but not focusing windows was done for bug 161174. I assume you are asking for an option to disable this behaviour?
Yeah, I knew somebody would complain the day this is fixed. Go to Alt+F3/Configure -> Actions and set 'Activate' as the action for something there you want.
I see from that bug that some people like it the new way. Yes, I would love an option to configure this. Under the Configure Window Actions I can configure the first three buttons without a modifier key, or the first three buttons + scroll wheel with a modifier key. If I could configure the scroll wheel without a modifier key, then that would be perfect. Lubos, is this a wontfix for reverting bug 161174 or a wontfix to configure the wheel sans modifier key ever (contrary to our options with the first three buttons)? I would be happy having this a wishlist item if there isn't some deeper reason to never do it.
It is a wontfix for the option. You said you want a way to activate a window without raising/etc. it, and you can set actions for that as described above. I don't see much sense in actually using a wheel for this, other than as a workaround.
*** Bug 172251 has been marked as a duplicate of this bug. ***
When I change windows, I always want to give the new window focus, although I only sometimes want to raise it, and I almost never want to change it. So, I use the left click to raise + activate, and mouse wheel to simply activate. Removing the mouse wheel option leaves me with no way of focusing a window without raising and it and without modifying it. Left click doesn't work, as explained above. Middle click pastes, and thus generally changes a window, and right click normally open a menu, meaning I'd have to click twice every time I wanted to switch a window (an ugly workaround at best). So, having only 3 mouse buttons (configurable or not), I'm left with the mouse wheel as my only option, which (as you're aware) isn't an option anymore. So, while you might not see any use for using the wheel in this manner, I don't see any use for using the wheel as it is in KDE 4.1.2.
*** Bug 173596 has been marked as a duplicate of this bug. ***
Why is this bug closed? I still don't see a way to make the mouse-wheel change focus. IMO, this is a major regression in KDE 4, and I greatly miss it.
I agree, Luke. KDE 4 is unusable for me unless this bug is fixed, either upstream or by manual patching every time (rather a nuisance). Unfortunately, comment #4 suggests they're not even interested in patches for this.
It is not obvious at all how to get old behaviour. I tried all combinations that made a little sense, and some that didn't and could get it to work. Ashamed to admit I can't see how to do it. Lubos, please show us the correct way of configuring those actions, or provide an option for the old Want a good use case: Open a browser and a text editor side by side without overlapping. With: Copy text from the browser, do a small scroll down over the text editor and paste the text exactly where the editing cursor was. Easier than alt+tab or having to go move the cursor over the title bar. Without: a)Copy the text, click inside the text editor and have the editing cursor move at some random point.
I do see neither an obvious nor any way to get the old behavior. So please enlighten me or add an option.
I'm agreeing with the people here, there should be an option.
I too would like "scroll to focus" to be a configurable option in kde4. As a long time KDE-user I've always found it immensely useful, and I use it constantly in KDE3.5.* One frequent scenario for me is; * Maximized 'konsole' in background. * Several non-maximized 'konsoles' on top, often overlapping each other, each doing various 'tail -f /var/log/something' or other. scroll-focus lets me run commands in the 'lowest-most' terminal, while observing it's effects immediately on the raised ones. In this scenario the ability to easily shift focus between windows (in order to modify whatever's tail -f'ing there) *without* disturbing the 'layout', is what's important to me. Personally I don't think it gets easier than scroll-to-focus, and I'm surprised to learn that this feature was intentionally removed... :(
*** This bug has been confirmed by popular vote. ***
Contrary to the advice given in comment 2, in KDE 4.1.3 it doesn't seem that I am able to set 'Activate' as the action for non-mouse button events. The list I see for modifier key + mouse wheel is: Raise/Lower Shade/Unshade Maximize/Restore Keep Above/Below Move to Previous/Next Desktop Change Opacity Nothing Even for modifier key + mouse button the only option which involves Activate is "Activate, Raise, and Move" which is clearly not the desired behavior.
Still an issue in KDE 4.2.
Created attachment 31807 [details] kwin patch trying to solve the bug Hi, I used some mimetism and created a patch to allow configuring the wheel. Go to Window Behaviour->Window Actions and set the Wheel to "Activate & Pass Click" to get the old behaviour. The last two options are not too coherently named, but I tried to keep the modifications to a minimum. Please have a look and tell me if it's ok and maybe what needs modified (the last two options names maybe).
I forgot to mention, it works.
Hi, Someone know if this patch will appear in any KDE official update?. I'm asking because I need it but unfortunatelly my computational skills are not good enough to compile source codes. Thanks
Hi, please give me some feedback on this change.
Since we're talking about the wheel here, does "pass click" mean "scroll"? If so, should the options perhaps be named: "Scroll", "Activate and scroll", "Activate, raise, and scroll"
I confirm that the change restores the old behaviour when applied to kwin 4.2.1
Created attachment 32357 [details] More coherent version
Can I get some feedback on this? Like "will apply", "change x" or "move along". The changes are pretty straightforward.
Just some further confirmation; Works with the 'more coherent' version on kwin 4.2.2 on openSUSE 11.1. Sorry it took so long to test and feed back :-/ Hope the patch gets accepted.
I'd like to see this, too, in the next version. I'm used to just use the scroll wheel to activate windows for example konversation and then type. It's very annoying if you have to click first now. I'm trying this almost every day and fail. So please change this. Thanks.
SVN commit 964140 by alspehr: Added setting to control whether scrolling on a background window focuses it. Patch by Alex Danila. Approved by lmurray. BUG: 164261 M +43 -3 kcmkwin/kwinoptions/mouse.cpp M +2 -0 kcmkwin/kwinoptions/mouse.h M +4 -0 options.cpp M +2 -0 options.h WebSVN link: http://websvn.kde.org/?view=rev&revision=964140
SVN commit 965103 by alspehr: This somehow escaped being included in r964140... CCBUG:164261 M +6 -2 events.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=965103
MUCH better, thank you! Confirming fixed in KDE 4.3.0.