Hi,
why is repositioning of windows delayed, when a window-actor is under
the pointer?
In my extension you can select, close and move windows with your
keyboard. So if it happens that one window is under the pointer, the
windows don't get repositioned.
Is this maybe some orphaned code from tim
Hi,
for extension development it would often be convenient, if there were
extension hooks for the onAnimationStart and onAnimationComplete
callbacks... Otherwise you have to use inexact magic numbers...
Best, Paul
___
gnome-shell-list mailing list
gn
On Thu, Jan 22, 2015 at 9:29 PM, Paul Neulinger wrote:
> why is repositioning of windows delayed, when a window-actor is under
> the pointer?
The reason is mentioned in the commit message[0] and the referenced bug report.
[0] https://git.gnome.org/browse/gnome-shell/commit?id=40b045917488504
___
Ok, thanks. Waiting for pointer movement or for the pointer leaving the
workspace makes sense. But to check if a window is under the pointer
does not, does it? This piece of code also does not appear in the bug
report. When you close a window - the use case mentioned in the bug
report - with a mous
On Thu, Jan 22, 2015 at 10:45 PM, Paul Neulinger
wrote:
> Ok, thanks. Waiting for pointer movement or for the pointer leaving the
> workspace makes sense. But to check if a window is under the pointer
> does not, does it? This piece of code also does not appear in the bug
> report.
Indeed, that p
Ok, but hovering or resting above a window doesn't mean dragging. Isn't
there a signal for that which could trigger the delay? And when I drag a
window I also move the pointer. This piece of code cannot be reached
when the window is in drag because the pointer moves and the previous
condition is m
