(*** This bug was imported into bugs.kde.org ***) Package: kwin Version: KDE 2.2.2 Severity: wishlist Installed from: Debian testing/unstable Packages Compiler: gcc version 2.95.4 20011006 (Debian prerelease) OS: Linux OS/Compiler notes: Not Specified KWin : Giving the focus to a window should occur on button up events (and not on button down) - this would make it possible to drag and drop without loosing focus Typical scenario: You have Konqueror and Konsole opened. Konsole has the focus. --==Konsole==---- | | | |=Konqueror=- | | | | > | | --============--- | |================| You need a file path and you want to drag and drop a file from konqueror to the konsole. As soon as you click on konqueror to grab the icon it gets the focus and overlaps konsole. When you drop the file on konsole the focus is not restored and you have to click again on it to raise it -- this can get annoying. Proposed solution : Have an option that the focus will be transfered on a window on "button up" and make that default for new users. Guillaume Pratte www.Gulus.org (Submitted via bugs.kde.org)
*** Bug 62089 has been marked as a duplicate of this bug. ***
Precisely, I was about to make a bug report about unable to drag and drop due to kwin behavior. kwin *should NOT* switch/shift/transfer the focus, when user "clicks and holds" the LMB or RMB mouse buttons on: 1. file 2. folder 3. selection (text) 4. selection (files/folders) it is like : "On click, wait till mouse button is released" before switching the focus of windows. without this the whole concept of drag and drop fails, due to current kwin behavior of switching focus as soon as mouse button is pressed (clicked) on a file. kwin should wait for release of mouse button to decide whether or not to switch the focus. other than the above mentioned, kwin should switch focus. thanks in advance.
totally right! this is especially annoying if you have a window maximized and another one over the maximized. if you start draging the not maximized window disapears, covered by the maximized one. thnx
Aren't there 2 separate events for mouse clicking (Down and Up)? I don't think it is so tecnically impossible to implement.
*** Bug 71499 has been marked as a duplicate of this bug. ***
While I agree with the original idea, a workaround has been implemented for some time (and is how its done in Windoze world) - while dragging, move the mouse to the Taskbar over the target applications icon for a moment and this application will be raised, after which you can finish the drag'n'drop action.
*** Bug 79779 has been marked as a duplicate of this bug. ***
I have to agree! This behaviour is very annoying. My personal opinion is that it would be nice if the user would be able to configure whether a single click should raise the window or not. Why don't provide the user with a complete configuration matric? follow mouse on click on double click triple_click focus raise With AmigaOS the users could configure this completely. For configuring the events the user had complete freedom in configuring the events. Examples: Action key_press, mouse_press, mouse_up - which key, which mouse button (left/middle/right) For mouse you could choose from (single,double, triple) clicks. You could tick whether the event shall be swallod or passed through. Examples: any_window: left_mouse_press (single) = active active_window: left_mouse_press (double) = raise The user could send any events he wanted. You could configure that double_right_click for example should iconify the window Or that double_left_click on a requester is always "OK" and double_right_click is "Cancel" and so on and so forth. You could configure all events (click, focus, raise, to front, to back, iconify, center, zoom, shrink, close, ok, cancel, ....) It would be nice if KDE would give their users the same configuration power as this 20 year old AMiGA system did. Cheers Gunnar
*** Bug 84552 has been marked as a duplicate of this bug. ***
maybe it should be in a different bug report, but I guess its related. dragging TO a window should maybe raise it, especially on a focus follow mouse policy.
Yeah the most annoying scenario: Try dragging a file from full-screen konqueror, to the gimp. It is actually impossible. First of all, konqueror should be raised on mouse up, not down. Doing it on the mouse down event makes it obscure gimp. Secondly, you hover over the gimp taskbar button, but that opens the little window selection menu and you can't actually click on either of the two gimp windows. Very annoying.
The correct effect can be achieved by setting KCC->Desktop->Window Behaviour->Inactive Inner Window->Left Click to "Activate & Pass click" Only problem is it does that for any click, not just drags.
*** Bug 108509 has been marked as a duplicate of this bug. ***
i see this wish (make drag'n'drop work) has been here since 2001, and other OS'es do this right since - what, always? anyway, i'm no programmer at all, but it doesn't SOUND complicated to do, so i guess no-one thought this was usefull or interesting? i think its seriously something that needs to be fixed, i'd rather call this an usability bug than a wish item. 4 other bugs have already been filled, and it seems to me the time spend on closing them -> duplicate would be close to the time it would take to fix this one? anyway, 263 votes might not make this a top-priority, but its a small thing that would make KDE better... and could be done for KDE 3.5.3, i hope. tough the first reporter might have thought this was usefull for KDE 3.0...
Totally agree about this being a usability issue. I really hope this is getting addressed at least in KDE4.
Ok I investigated how windows does this, and its algorithm is this: On mouse-down, if the clicked item can be dragged, do nothing, otherwise raise and pass click. If it is possible for the item to be dragged, wait for mouse-up or mouse-move to decide what to do. The trouble with implementing this on linux, is that there is no easy way (afaics) to tell whether the item under the mouse can be dragged. I looked in Qt a while ago, and QWidget's don't seem to make that information available - to support d&d you just modify the onMouseMove event (or something).
hmmm, so QWidget has to be modified (if possible) for this to work? well, as Trolltech was/is working on more/better usability, this might be something they want to do...
Hell! This very same annoying behaviour is there in Dolphin/KDE 4. I'm using the OpenSuSE live CD with KDE 4 rc2.
I would like to point out that on Windows, usually a window moves to the foreground on mousedown, but if you click on something that can be dragged, it waits for the mouseup event. This appears to be a compromise between moving windows to the foreground as early as possible, while still avoiding drag and drop problems.
I guess, this "switch focus on button down" behavior is part of QT/kdelibs not kwin. Please, because of this bug, kde's drag and drop is disappointing. A modern desktop can't do basic DnD even after 7 years which Windows 95 could do very well :(
you should try dragging and dropping a file from a window to another using Exposé on OSX
Just had a thought. Recently (maybe with Qt 4) the 'What's this?' button seems to have had an excellent improvement: When you hover over a widget that has What's This text, the mouse cursor changes from a no-entry style to a question mark. Isn't this almost exactly what is needed to solve this bug? On second thoughts it probably works by responding to the mouse move event for the whole app and modifying the cursor. So using this method would a) Do stuff on all mouse moves, and b) Need a way for the app to control when the window is raised (while respecting the window manager policies).
*** Bug 189467 has been marked as a duplicate of this bug. ***
This can be achived in the following ways: By clicking the middle mousbutton when you drag and drop Alternatively you can configure your left mouse button by going into KSystemSettings> Window behaviour> Window Actions. Set the behaviour for the left mouse button to "Activate and pass click"
(In reply to comment #24) > By clicking the middle mousbutton when you drag and drop Oh.. this is cool. Thanks. It seems to be a satisfactory workaround. > Alternatively you can configure your left mouse button by going into > KSystemSettings> Window behaviour> Window Actions. Set the behaviour for the > left mouse button to "Activate and pass click" But this makes it necessary to click on a background window twice to raise it. If I remember right, I had tried this once but dropped it because of this inconvenience.
Created attachment 39052 [details] Workaround for bug 36065 Workaround for bug 36065. I recommend we resolve this bug and make a clone calling for change in default setting.
Kenneth: Those settings don't produce the correct behaviour. I already mentioned this in comment 12. Fixing this properly involves modifying Xorg, and probably Qt as well. Given the age of this bug I can't really see it happening ever.
QT guys please just making "mouse release" as "switch focus" will solve this! Because of this bug I haven't been able to: 1. copy files/folders across windows. 2. copy paste selection across windows. without the annoyance of visual distraction. And the hover on taskbar is really slowing it whole process down. And the new "take 50% desktop window alignment" in kde 4.4beta2, still causes trouble of "the loss of focus to the unexpected/undesired window" 1. the "inactive window becomes active" causing the user to click again on the previously active window.
In KDE 4.6 it gets even worse. With the newly introduced “Windows 7 like launchers” where you can place any file/document in your taskbar, the dragging-to-raise-window feature no longer works. So dragging a file out of a window to the taskbar and then waiting for the target window to raise to drop the file there no longer works! You *always* need to either use split view (in Dolphin) or re-arrange both windows, so you see them all and drag elements directly. This is just aweful! (It works with Smooth Tasks widget, though, so it is definitly due to the launcher thingie)
*** Bug 195773 has been marked as a duplicate of this bug. ***
Man, this bug is making me feel old. Does anyone know if they've done this right with Wayland? They've got the perfect opportunity to fix it but I bet they've made exactly the same mistake.
> Does anyone know if they've done this > right with Wayland? I have not yet implemented Drag'n'Drop support for Wayland in KWin, so I cannot say whether it is fixed. But given the design of Wayland I don't see a reason why this bug should not be fixable.
@Martin: that's awesome news :D
Earlier I found that it requires toolkit support (see comment #16). It's not something I'd naturally think of if I was designing Wayland... Let's hope they do though!
Not that I want to discuss about it, as it is premature... With Wayland control of input, drag'n'drop and raising/lowering windows is completely moved into KWin. Windows will (at least with KWin as Wayland server) not be able to raise themselves any more. All this is controlled by the Compositor which does enforce a policy on the clients. Because of that I don't see why this bug should not be fixable with Wayland. KWin controlls the mouse and knows whether a drag'n'drop has been started or whether the window should be activated and raised on mouse click.
But Windows is able to slightly improve the usability by knowing *before* mouse-up whether a click *can* be a drag. If it can't (i.e. you clicked something non-draggable) then it raises the window immediately. This requires a reply to all mouse-down events from the window saying "This might be a drag, don't raise me immediately" or "There's no chance this is a drag, raise me now." I had a look at the Wayland protocol, and it doesn't seem to include anything like this. Of course you could simply always wait for mouse-up, but then it will seem less responsive.
No, windows works completely different. The "clients" have far more control about "window management", ie. when you click into explorer it of course knows where you click and then in doubt doesn't trigger a raise. To do this on X11 and probably wayland, you'd *have* to activate & pass the click on mouse press and raise the window on mouse release (if there's not not been an interim DnD) - you cannot rely on "the toolkit" since there's not "/the/ toolkit". *Theoretically* this *could* be done on X11, BUT (big, fat: BUT) it would require a permanent passive mouse grab on active clients (just as kwin atm. passively grabs inactive clients and releases that grab when they fall active) so kwin would also receive mouse release events for the activated client (and all others) Since one probably had to monitor only the first[1] mouse release after the activation (assuming that an already activated client is also always risen in this activation model, true about 99% of the time) this should actually not be "too" harmfull (but mess the code a bit ;-) and if it wasn't for "KWin" (but some tiny WM with 3 users) i'd perhaps just write a patch, but freaking around with mouse grabs is about the worst thing one can do on X11 (otherwise kwin could resize borderless windows by now w/o stupid overlay corners) so i'd never really guarantee for such a patch. [1] FTR: it's not that trivial, DnDs might likely actively grab the pointer and then you receive the wrong or no mouse release
*** Bug 277809 has been marked as a duplicate of this bug. ***
*** Bug 196137 has been marked as a duplicate of this bug. ***
Anybody knows if things have changed in these 2 and a half years? This is pretty annoying. (I'm using KDE on Kubuntu 14.04)
No. This is a structural problem. The wish was opened 2001-12-12 01:27:14 against KDE 2.2.2. Also KWin4 is meanwhile feature frozen for some time. Don't expect a solution on X11 or KDE4. See comment #35 about the KWin5/Wayland situation.
I started working on drag'n'drop support for Wayland and also looked at a solution for this problem. This morning I discussed ideas with our usability team and we will also do some iterative in person tests next week during our development sprint. So far we concluded that the best approach is to implement a raise on hover approach. As soon as the mouse enters another window during drag that one will be raised to give a clear field for the drop. At the moment the keyboard focus (aka active window) will stay with the window dragged from after the drop. It is difficult to say what the user expects to happen after the drop. Both cases working with the window dragged from and working with the window dragged to are equally possible. The current implementation follows the focus policy: with click to activate the focus stays with the window dragged from, with focus follows mouse the window dragged to will activate.
Git commit 8a1f19b1450fc244977ad6e7dff48d4fb6c28a13 by Martin Gräßlin. Committed on 02/03/2016 at 07:34. Pushed by graesslin into branch 'master'. Add support for Drag'n'Drop on Wayland Drag'n'Drop on Wayland allows us to improve the drag'n'drop experience. When entering a window during the drag'n'drop operation, KWin raises it. FIXED-IN: 5.6.0 (Wayland only) M +42 -0 input.cpp M +115 -0 pointer_input.cpp M +7 -0 pointer_input.h http://commits.kde.org/kwin/8a1f19b1450fc244977ad6e7dff48d4fb6c28a13
(In reply to Martin Gräßlin from comment #42) > > So far we concluded that the best approach is to implement a raise on hover > approach. As soon as the mouse enters another window during drag that one > will be raised to give a clear field for the drop. I'm not sure if that'd suffice. Consider the situation: 1. The 'source' window is behind the 'destination' window initially 2. The source window would cover the destination window completely if it is raised 3. Because the source window is behind the destination window initially, the destination window is visible 4. Now the user wants to drag something from the source window to the destination window 5. The user starts to drag some item from the source window. 6. If the source window is raised, the destination window is no longer visible so 'hovering' over it is not possible! PS: I am extremely happy to see this bug being worked up on. Thanks a million for all the great work you guys are doing.
> I'm not sure if that'd suffice. Consider the situation: We considered this situation during our discussions and came to the conclusion that it's out of scope. The drag is performed from the active window, for the compositor it's impossible to know that the user clicked the window to perform a drag and that's also not how the Wayland protocol allows to start a drag (the click must(!) be passed to the window). There are multiple ways now to circumvent the problem: * mark the "destination" window as keep above * use Alt+Tab during drag and drop to change window * use Present Windows (that needs implementation) to change window * use task bar to switch windows We also think that the users are able to realize that they cannot drag from a maximized window and will change the geometry before. Just like users use split screen in Dolphin to better support drag'n'drop.
(In reply to Martin Gräßlin from comment #45) > > I'm not sure if that'd suffice. Consider the situation: > > We considered this situation during our discussions and came to the > conclusion that it's out of scope. The drag is performed from the active > window, for the compositor it's impossible to know that the user clicked the > window to perform a drag and that's also not how the Wayland protocol allows > to start a drag (the click must(!) be passed to the window). The problem is that this raise happens not on 'click' but on mouse-down itself. > > There are multiple ways now to circumvent the problem: Exactly! These are ways to 'circumvent' the problem. The problem exists and it is disappointing to see that it'd still need to be worked around even though we now have a perfect opportunity to fix this - Wayland new Qt etc etc. > > We also think that the users are able to realize that they cannot drag from > a maximized window and will change the geometry before. Just like users use > split screen in Dolphin to better support drag'n'drop. Hmm.. Users are not just 'able' to realise. They are forced to. And all these workaround statements can be equally applied to removing drag & drop altogether (for Dolphin, for example) saying that "users can just do Ctrl+C/X & Ctrl+V". Anyway, if this is how we are 'fixing' this bug, please close it as WONTFIX rather than FIXED. Because that's what's happening to this bug report. No offense.
(In reply to Syam from comment #46) > The problem is that this raise happens not on 'click' but on mouse-down > itself. This is correct, the raise happens on press if that's the action you configured for what happens on click on inactive window. This is configurable. If you don't like the default of "Activate, Raise & Pass Click" change it to "Activate & Pass Click". Changing the action to be performed on release instead of press would be rather weird. The window would not activate till you release. That's not what a user (and applications) expects. If we had any chance to know that the user intends to drag we could perform a different strategy. To me the issue is fixed. This bug report contains multiple suggestions on how it should behave. Several of them even contradicting. If we should only mark it as fixed when all of them are fixed, it won't happen. I consider it as fixed as the actual problem is fixed. Now as I'm the only one here who probably has tried this out, I ask you to first try it before starting discussions about the state of this bug report. Also I'm not interested in discussions whether it's fixed or wontfixed. I have better things to do with my dev time (like fixing 14 year old bug reports).
(In reply to Martin Gräßlin from comment #47) > (In reply to Syam from comment #46) > > The problem is that this raise happens not on 'click' but on mouse-down > > itself. > > This is correct, the raise happens on press if that's the action you > configured for what happens on click on inactive window. This is > configurable. If you don't like the default of "Activate, Raise & Pass > Click" change it to "Activate & Pass Click". This has been suggested earlier. But it doesn't really work, because the setting is really for mouse-down and not a 'click' (which is completed at mouse-up). With "Activate and Pass click", the window won't be raised after one click. The user needs to click on it again to raise it. And that is indeed weird, I agree. > > Changing the action to be performed on release instead of press would be > rather weird. The window would not activate till you release. That's not > what a user (and applications) expects. Is it really weird? I wonder how it is done on Windows? Does the background window raise at mouse-down itself or only on 'click', i.e. after mouse-up? I have to boot in to a Windows machine before confirming. > If we had any chance to know that > the user intends to drag we could perform a different strategy. I see from some earlier comments that the devs are stuck on this 'angle' to solve the problem. But as mentioned in the original report, 'raising at mouse-up and not immediately after mouse-down' would solve it without any need to know if a drag is being done. > > To me the issue is fixed. This bug report contains multiple suggestions on > how it should behave. Several of them even contradicting. Well, the original report mentions one problem and one solution. I understand that it is difficult to implement this with current technology - as pointed out in some earlier comment, on current Linux desktops & GUI libraries, everything seems to happen at mouse-down and not on mouse-clicks. > > Now as I'm the only one here who probably has tried this out, I ask you to > first try it before starting discussions about the state of this bug report. I am deeply sorry if my earlier comment offended you. I was afraid if it'd come out like this. But I didn't mean any disrespect. I have very high regards for devs, especially you :-)
(In reply to Syam from comment #48) > (In reply to Martin Gräßlin from comment #47) > > (In reply to Syam from comment #46) > > > > Changing the action to be performed on release instead of press would be > > rather weird. The window would not activate till you release. That's not > > what a user (and applications) expects. > > Is it really weird? I wonder how it is done on Windows? Does the background > window raise at mouse-down itself or only on 'click', i.e. after mouse-up? I > have to boot in to a Windows machine before confirming. Just checked on Windows. You are right. The raise happens on mouse down itself, unless its a drag.
FYI, on windows, window management is completely done by the clients (so a client knows that this is gonna be a drag and can avoid the self-raise) The WM_TAKE_FOCUS protocol (despite the focus has really nothing to do with the stack order) pointed that direction (and sucks terribly because of broken client implementations... letting alone the focus stealing problems) Raising on MB release would be possible (on caveats, see comment #37), but just cause other behavioral problems (if the user didn't want to drag something, but draw a selection frame etc.) About present windows to the rescue: *cough* https://git.reviewboard.kde.org/r/105341/ **COUGH** :-P Last thought: detect the drag (maybe even on X11 by listening to dnd messages rather than "something grabbed the pointer") and restore the stack if it happened within "the dnd timeout™" (which doesn't exist either - there's no guarantee Qt and Gtk wait the same amount of time), ie. lower the window we just raised (while even that could be nasty: assume the user wanted to dnd within the just raised client and suddenly it lowers again) tl;dr - clean up your f**** desktop ;-P