[Bug 38753] Re: Inactive window "raise on click" should occur after click is released
Bug Watch Updater
38753 at bugs.launchpad.net
Sat Aug 2 11:33:44 UTC 2014
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 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
More information about the kubuntu-bugs
mailing list