Launchpad has imported 42 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=36065.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2001-12-12T01:27:14+00:00 Pratg00 wrote: (*** 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) Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/0 ------------------------------------------------------------------------ On 2003-08-06T11:15:06+00:00 L-lunak-5 wrote: *** Bug 62089 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/1 ------------------------------------------------------------------------ On 2003-11-17T22:42:22+00:00 fast_rizwaan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/2 ------------------------------------------------------------------------ On 2004-02-07T10:38:53+00:00 Gregor-burger wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/3 ------------------------------------------------------------------------ On 2004-02-12T17:31:27+00:00 alx5000 wrote: Aren't there 2 separate events for mouse clicking (Down and Up)? I don't think it is so tecnically impossible to implement. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/4 ------------------------------------------------------------------------ On 2004-02-27T15:33:06+00:00 L-lunak-5 wrote: *** Bug 71499 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/5 ------------------------------------------------------------------------ On 2004-03-18T09:39:04+00:00 Aavo wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/6 ------------------------------------------------------------------------ On 2004-04-17T11:47:26+00:00 L-lunak-5 wrote: *** Bug 79779 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/7 ------------------------------------------------------------------------ On 2004-05-27T11:50:47+00:00 Gunnar-o wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/8 ------------------------------------------------------------------------ On 2004-07-14T13:34:39+00:00 L-lunak-5 wrote: *** Bug 84552 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/9 ------------------------------------------------------------------------ On 2004-08-19T22:36:52+00:00 Opensource-b wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/10 ------------------------------------------------------------------------ On 2005-03-26T16:40:12+00:00 Timmmm wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/11 ------------------------------------------------------------------------ On 2005-05-20T12:24:00+00:00 Timmmm wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/12 ------------------------------------------------------------------------ On 2005-07-18T10:04:23+00:00 L-lunak-5 wrote: *** Bug 108509 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/13 ------------------------------------------------------------------------ On 2006-04-05T12:03:52+00:00 Jospoortvliet wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/14 ------------------------------------------------------------------------ On 2006-04-05T23:43:38+00:00 Siyuan-nz wrote: Totally agree about this being a usability issue. I really hope this is getting addressed at least in KDE4. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/15 ------------------------------------------------------------------------ On 2006-08-21T23:47:01+00:00 Timmmm wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/20 ------------------------------------------------------------------------ On 2006-08-22T08:23:12+00:00 Jospoortvliet wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/21 ------------------------------------------------------------------------ On 2007-12-15T06:23:46+00:00 Get-sonic wrote: Hell! This very same annoying behaviour is there in Dolphin/KDE 4. I'm using the OpenSuSE live CD with KDE 4 rc2. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/22 ------------------------------------------------------------------------ On 2008-01-20T07:27:09+00:00 Shinobu Maehara wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/23 ------------------------------------------------------------------------ On 2008-08-23T14:02:04+00:00 fast_rizwaan wrote: 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 :( Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/26 ------------------------------------------------------------------------ On 2008-08-24T00:56:21+00:00 Opensource-b wrote: you should try dragging and dropping a file from a window to another using Exposé on OSX Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/27 ------------------------------------------------------------------------ On 2008-09-15T16:35:47+00:00 Timmmm wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/28 ------------------------------------------------------------------------ On 2009-09-06T22:13:41+00:00 Mgraesslin wrote: *** Bug 189467 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/29 ------------------------------------------------------------------------ On 2009-12-14T12:24:09+00:00 KennethAar wrote: 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" Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/31 ------------------------------------------------------------------------ On 2009-12-14T14:50:07+00:00 Get-sonic wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/32 ------------------------------------------------------------------------ On 2009-12-14T18:42:26+00:00 KennethAar wrote: Created attachment 39052 Workaround for bug 36065 Workaround for bug 36065. I recommend we resolve this bug and make a clone calling for change in default setting. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/33 ------------------------------------------------------------------------ On 2009-12-14T19:20:55+00:00 Timmmm wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/34 ------------------------------------------------------------------------ On 2010-01-06T06:54:22+00:00 fast_rizwaan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/35 ------------------------------------------------------------------------ On 2011-02-24T09:23:08+00:00 BajK wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/36 ------------------------------------------------------------------------ On 2011-07-01T15:11:01+00:00 Thomas-luebking wrote: *** Bug 195773 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/37 ------------------------------------------------------------------------ On 2011-07-01T20:13:07+00:00 Timmmm wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/38 ------------------------------------------------------------------------ On 2011-07-02T04:58:31+00:00 Mgraesslin wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/39 ------------------------------------------------------------------------ On 2011-07-02T09:11:18+00:00 Jospoortvliet wrote: @Martin: that's awesome news :D Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/40 ------------------------------------------------------------------------ On 2011-07-02T09:44:38+00:00 Timmmm wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/41 ------------------------------------------------------------------------ On 2011-07-02T09:55:11+00:00 Mgraesslin wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/42 ------------------------------------------------------------------------ On 2011-07-02T10:26:02+00:00 Timmmm wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/43 ------------------------------------------------------------------------ On 2011-07-02T12:05:57+00:00 Thomas-luebking wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/44 ------------------------------------------------------------------------ On 2011-07-15T07:02:13+00:00 Thomas-luebking wrote: *** Bug 277809 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/45 ------------------------------------------------------------------------ On 2011-12-04T18:17:55+00:00 Kde-2011-08 wrote: *** Bug 196137 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/46 ------------------------------------------------------------------------ On 2014-08-02T04:42:46+00:00 marco wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/47 ------------------------------------------------------------------------ On 2014-08-02T06:43:24+00:00 Thomas-luebking wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+bug/38753/comments/48 -- 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
