Another trivial cleanup. This is in preparation for next commit, that
will expand on this if clause, and will make it a bit more complicated.
Using a variable here makes it easier to read.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
This setting (by default, 0) sets a time threshold in order to allow
DnD. If the drag is shorter than this threshold, DnD will be cancelled,
and event handling left to the next handlers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
Some drag actor parents might change their width to 0 after the drag
actor has been removed. If the drag is now canceled and the drag actor
is animated to return to the current parent position and scale, this
scale can not be determined and falls back to 1.0. This might be wrong
and can result in the drag actor being too large/small at the end of the
return animation.
To avoid this calculate the scale of the parent by recursively
calculating the product of its parents individual scales.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4017
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1790>
The original parent of a dragged actor might have been destroyed after
the drag has been started. When the drag is canceled and _dragOrigParent
is set, the code is trying to get the current position and size of it
when restoring. With a destroyed parent this however would result in a
crash.
This could happen for example when starting a drag on a window preview
while the overview is hiding and then releasing it once the transition
is done.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4024
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1817>
Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
The code to update the actor position based on the cursor and current
scale was run in a 'new-frame' handler. This is working fine when
animations are enabled, but when they are turned off this does not work.
This is because the 'new-frame' signal is emitted before the changes for
that frame are applied. So with animations off the position was only
ever updated with the starting values. As a result the shrunk actor was
not being dragged by the position where it was clicked, but by where it
was clicked in the original size, which is likely not even on the shrunk
actor.
This change now also updates the position in the onComplete handler
which gets run with the final scale, even if the duration is 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1627>
Commit de610a13f1ad1e7e34d4b9a81df58d4da3693059 in mutter made it
impossible to access the actors last allocation after unmapping it,
this broke the scale-up/down animation when starting a drag.
Fix that animation again by saving the actors transformed size before
unparenting (and therefore unmapping) the actor instead of afterwards.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1475
For drag actors which get reparented to the uiGroup, we currently wait
until the next input event to set the fixed position of the actor, until
that they will just be allocated their old fixed position, which is 0,
0.
So avoid drag actors flickering at the top left for one frame and
position them correctly right after reparenting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly adjust for drag actors which were allocated using a custom
vfunc_allocate() and might not have gotten allocated their preferred
size. When DND reparents the actor to the uiGroup, the drag actor will
get allocated its preferred size, so we also need to take the difference
between the old allocation size and the preferred size into account
before reparenting to the uiGroup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly handle drag actors which are not allocated using a fixed
position and disable the fixed position we were using to move the actor
around before we reparent it again to its original parent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Clutter originally cluttered its namespace with key symbols, before
prefixing all symbols with KEY. We still use the unprefixed symbols
occasionally, replace them so mutter can drop the deprecated symbols.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/808
In the case of bugs in a drag target's acceptDrop() function, it may
throw an exception. In the previous code, this would break out of the
loop entirely and never cancel the drag, so the mouse button release
event would be ignored and you would have to press Esc to get out of the
drag.
In this change, if acceptDrop() throws an exception, we log it and move
on to the next parent target instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/777
When a drag is cancelled and the source actor
is visible, the drag actor is animated back to
the source position. The scale that the drag
actor will become is calculated as:
scale = this._dragActor.width / sourceScaledWidth
However, this is wrong; what we wanted to do
is the opposite:
scale = sourceScaledWidth / this._dragActor.width
Fix the scale calculation to match the math
above.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Those checks were carried over from the very first DND implementation;
if they were ever actually required at all, this is no longer the case
as we moved away from Tweener for all our animations.
The number of cases where an extension is still using Tweener, creates
draggable actors, *AND* requires the checks for proper functioning
should be indistinguishable from zero, so drop the code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/669
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
We are currently inconsistent on whether case labels share the same
indentation level as the corresponding switch statement or not. gjs
goes with the default of no additional indentation, so go along with
that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
This call just went through stomping over previous drag operations if any,
_maybeStartDrag() accounted for this, but other callers (well, WindowClone
in workspace.js) don't. This must bail out early even if a drag operation is
requested, luckily all callers account for it already.
This broke shell state by preserving connected captured-event handlers if
one tried to drag multiple windows simultaneously through multitouch. We
of course don't support that, now more elegantly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/455
With the recent port to JS6 classes, the trailing
comma after functions in the syntax of classes has
been removed.
However commit c2961f21 accidentally reintroduces
one trailing comma after a newly created function,
leading into g-s throwing an exception and not
starting anymore.
Therefore, remove this trailing comma to solve
this problem.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/366
Besides the device grab on the drag device, also set up a captured-event
handler to catch other devices (except the keyboard) while the DnD
operation is ongoing. This makes DnD operations exclusive to others.
Also, disallow it in less aggressive ways if maybeStartDrag() gets called
while there is a current draggable.
This might definitely be nicer (eg. having other grabbed devices emit
leave/end events), but can't be done without major surgery to Clutter.
In the case where the draggable has an actor of its own, state could be
left broken when dragging on a place that would not accept the DnD op.
After button release, drag state is set to "cancelled" and the animation
begins. After the animation is finished, the drag actor would be destroyed
before disconnecting from its destroy handler.
Within the destroy handler, the grab would be undone but drag state would
be left on "cancelled" state for subsequent operations. This results in
DnD oddities and stuck grabs.
In order to fix this, double check in the actor destroy handler that we
are actually dragging before setting the "cancelled" state.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
Instead of fetching the CLUTTER_POINTER_DEVICE device. It will
be wrong if drags get initiated from tablet pointers. This allows
for DnD operations to be started, moved, and more importantly
finished through tablet devices.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
