https://bugs.kde.org/show_bug.cgi?id=455355
--- Comment #7 from Christian (Fuchs) <k...@fuchsnet.ch> --- (In reply to Marco Martin from comment #6) > This was a pretty obscure feature, assigning random actions to buttons (that > one, moving a window to whatever the current desktop was, doesn't seem > particularly intuitive) while a drag and drop is not much longer to perform > than that. They were not exactly random since there was a GUI to configure them and I think it wasn't enabled by default. Thus also not proposing to bind it to a fix mouse button, but rather offer the very same configuration GUI we offer for mouse actions on the desktop, which would be consistent and then people would know what buttons do (including close, which, compared to pull, is a destructive and in many cases not undoable action). Drag and drop simply doesn't work because the effect is also used for selecting one window out of many (e.g. when you click on a grouped task in the taskbar) and for the present window effect, where you do not have the virtual desktops shown and so you can't drag and drop. A decent usecase to demonstrate is: you have n (where n >= 2) windows of the same app open, say, konsole, and you open present windows by clicking on the taskbar entry. With that mouse button you could quickly pull all of these windows to your current virtual desktop. > to have more immediate features like that, we need some good design analysis > beforehand, for now moving as feature request, should be discussed with VDG > for further action I did discuss this in the VDG group as well, as far as memory serves if configurable consistently as other places where we allow custom mouse actions (e.g. the desktop) this would be fine. This would also solve the issue of currently having a (needed, don't get me wrong, it's a good feature) destructive action on one of the mouse buttons with no visual clue to the user that this will happen. -- You are receiving this mail because: You are watching all bug changes.
