Version: (using Devel) Installed from: Compiled sources When I the Desktop activity is set as "Desktop" we can switch desktops with the mouse wheel but when is set as "Folder view" mouse wheel dosn't work. Then you are forced to click on the pager or keyboard shortcuts to change desktops. I think that is because the fodlerview desktop mode has the behavior of the folderview widget . I'm using: KDE 4.2.0 & KDE 4.3 (>= 20090204) Qt: 4.4.3
*** This bug has been marked as a duplicate of bug 180725 ***
Oops, wrong tab/bug.
I know few people that are pissed off by not having ability to switch desktops with mouse wheel, as they were accustomed to do. From usability point of view, this should "just work", ether in "desktop" or "folderview" mode, otherwise people will get angry. Similar to "Super" button not opening the menu (bug 154564).
*** Bug 191537 has been marked as a duplicate of this bug. ***
Still present in 4.3
oh yuck. it's still broken in trunk. more mouse events that folderview is eating before plasma can get to them, I guess. :/ I kinda wish I could just override it.
*** Bug 227039 has been marked as a duplicate of this bug. ***
*** Bug 228287 has been marked as a duplicate of this bug. ***
This bug is more than one year old, any chance to have it fixed in the next year?
it is not. mouse actions were only released in 4.4, which has been out less than a month. and no, it's not likely to be fixed any time soon... it's a nasty bug.
holy crap, it actually *is* that old. it's been a problem since long before mouse plugins existed... well, in that case it's really *really* unlikely to be fixed.
wasnt that the qt 4.5 specific stuff you where working on at tokomak one year ago? something about the events that are not passed from folderview further down... don't remember exactly
6 months ago, and that was an awful nasty hack that got right-click working properly. it was a different problem from scroll-wheel, because it was actually mouse plugins eating events that folderview should get, so I was able to explicitly pass them on...
I don't know how's the code, but I can imagine that srolling could have some problems because in folderview plasmoid it is used to scroll the plasmoid, but I can't understand why if I choose ctrl+scroll it works
because ctrl+scroll isn't used by folderview. scroll wheel is. but can we please stop using bugs.kde.org as a replacement for forum.kde.org? my bugs email folder is completely useless due to chit chat like this drowning out the actually useful and relevant comments being made on bug reports. post a patch, add new useful-to-writing-a-patch data (e.g. ways to reproduce, etc) or post on forum.kde.org. thanks.
SVN commit 1099064 by aseigo: if we are a containment and have no scrolling to do ... don't. BUG:183599 M +4 -3 iconview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1099064
I have to reopen it. Left click does not work in folderview mode, but in Desktop mode. I have assigned a quick application menu to the Left mouse button. It does work sometimes, e.g. if you use Right click to show the menu, then dismiss it with Left click, then Left click again the configured mouse action works. Additionally, Left click does not respect the QApplication::startDragDistance() and startDragTime(), so the above does not work when used with a high resolution input device, such as a tablet, where it is impossible to click without a slight drag.
*** Bug 234110 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > I have to reopen it. Left click does not work in folderview mode, but in > Desktop mode. I have assigned a quick application menu to the Left mouse > button. I will make it work with the left mouse button, but you won't be able to do elastic-band selections when you have a mouse action assigned to that button. > Additionally, Left click does not respect the QApplication::startDragDistance() > and startDragTime(), so the above does not work when used with a high > resolution input device, such as a tablet, where it is impossible to click > without a slight drag. Left click certainly respects startDragDistance(), and always has. It doesn't use startDragTime() because that's only meant to be used by text editors.
SVN commit 1126346 by fredrik: If a containment action is assigned to the left mouse button, give it precedence over elastic-band selections. Fixed in: 4.4.4 BUG: 183599 M +12 -0 iconview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1126346
*** Bug 241595 has been marked as a duplicate of this bug. ***
Will this bug fixed in 4.5? It is nasty ugly annoying bug.
er, yes, it's marked as fixed. :) in fact, fredrikh's last comment there says it's fixed in 4.4.4 as well.
No, in 4.4.4 it is not fixed. I have desktop set to the activity Folder view and it simply ignores scroll wheel. In Desktop mode it works like a charm.
the commit mentions the left mouse button, perhaps the mousewheel is still not working?
hrrm. there was a separate BR for the scroll-wheel not working, and iirc aseigo fixed it a while ago... but maybe that fix wasn't backported to 4.4? *tests* vertical scroll wheel works just fine in trunk. so you can either wait for 4.5 or go track down that report and ask if it can be backported to 4.4.5 :)
It is not fixed in 4.4.5
It is fixed in KDE SC 4.5.1 - finally I can switch folderview desktops by mousewheel. Thanks.