Drag down from panel to restore does not instantly lock window position relative to mouse cursor.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
Invalid
|
Undecided
|
Unassigned | ||
Unity |
Invalid
|
Undecided
|
Unassigned | ||
compiz (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
unity (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Ubuntu 11.04, Unity 3.8.16-
A nice feature of unity when using two monitors with TwinView is the ability to pull down a maximised window (restore) from one screen and drag it to the top of the other to maximise it there. This feels very natural and lends itself to a swift movement. It seems that the intention for a drag down is that the restored window be positioned such that the mouse cursor is at the top and middle of the window's title bar, as is the case it the action is performed very slowly. When the action is performed swiftly, there is an offset from this position, as if some initial part of the mouse displacement is excluded. This means the mouse cursor ends up lower down in the window, and for a swift manouevre from the left screen to the right for example, the window also ends up behind its intended position (i.e. centred left of the mouse cursor). While this does not prevent the user from maximising the window on another screen (and so does not constitute of a loss of functionality), it is a real detriment to the ergonomics of the operation, which I would say ranks it slightly above a purely cosmetic bug.
Unfortunately at the current status to make this work in unity has been used a workaround which uses X raw calls to move a window. So apparently it seems that the compiz grid plugin (which is charge to restore a window) waits a too much time before restoring the moved window.