[Bug 38753]
(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 received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/38753 Title: Inactive window "raise on click" should occur after click is released To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/38753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 38753]
(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 received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/38753 Title: Inactive window "raise on click" should occur after click is released To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/38753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 38753]
(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 received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/38753 Title: Inactive window "raise on click" should occur after click is released To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/38753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 38753]
(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 received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to kdebase-workspace in Ubuntu. https://bugs.launchpad.net/bugs/38753 Title: Inactive window "raise on click" should occur after click is released To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/38753/+subscriptions -- kubuntu-bugs mailing list kubuntu-b...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
