[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 Eduardo changed: What|Removed |Added CC||zl...@hotmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #50 from Thomas Lübking --- 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 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #49 from Syam --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 Ismail Donmez changed: What|Removed |Added CC|ism...@i10z.com | -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #48 from Syam --- (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 :-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #47 from Martin Gräßlin --- (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). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #46 from Syam --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #45 from Martin Gräßlin --- > 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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #44 from Syam --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 Martin Gräßlin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version Fixed In||5.6.0 (Wayland only) Resolution|--- |FIXED Latest Commit||http://commits.kde.org/kwin ||/8a1f19b1450fc244977ad6e7df ||f48d4fb6c28a13 --- Comment #43 from Martin Gräßlin --- 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 -0input.cpp M +115 -0pointer_input.cpp M +7-0pointer_input.h http://commits.kde.org/kwin/8a1f19b1450fc244977ad6e7dff48d4fb6c28a13 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 36065] dragging from a window should not raise it
https://bugs.kde.org/show_bug.cgi?id=36065 --- Comment #42 from Martin Gräßlin --- 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. -- You are receiving this mail because: You are watching all bug changes.
