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
The picked target actor may be destroyed (e.g. hover style change
resulting in the ClutterTexture to be destroyed). If we don't handle
this, GJS will abort when it sees the exception caused by Javascript
code trying to access the destroyed target actor.
To handle it, listen on the 'destroy' signal on the target actor, and
repick, so a valid actor is passed to the next motion callback.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/632
We need to avoid that we use the _dragActor instance after that it has
been destroyed or we'll get errors. We now set it to null when this
happens, protecting any access to that.
Add a DragState enum-like object to keep track of the state
instead of using booleans.
Remove duplicated handler on 'destroy' and just use a generic one.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
If the drag actor is destroyed before the animation
callback is called, the callback is never called and
we're sticked with dnd grabing the events after we
dropped the target.
https://bugzilla.gnome.org/show_bug.cgi?id=757676
We need to keep track of the pointer emulating touch sequence. In order
to have events properly redirected on touch devices, the
Clutter.grab_pointer and ungrab_pointer() have been replaced by the grab()
and grab_sequence() ClutterInputDevice methods, one or the other is used
depending on the device triggering DnD.
An extra "sequence" argument has been added to startDrag, passing null here
will resort to pointer grabs.
This is enough to make thumbnails in the WorkspaceBox draggable through
touch.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
Removing an existing source before scheduling a new one is not wrong,
but slightly less effective than doing nothing and relying on the
previously created source to do the job.
https://bugzilla.gnome.org/show_bug.cgi?id=711555
As the handler returns false, the corresponding source is removed
automatically and its id invalidated. Reset the id to 0 to reflect
this, otherwise newer versions of GLib will print a warning when
we later try to remove it explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=711555
I thought that cancelDrag was called for completed drags as well,
but it's not. Move the updateHoverId source removal to dragComplete.
This fixes "this._dragActor is undefined" warnings after completed
drags.
https://bugzilla.gnome.org/show_bug.cgi?id=707935
It turns out that picking a 3200x1200 scene on notebook chipsets
every time the mouse is moved isn't exactly the fastest thing. Defer
picking to an idle to ensure that it won't get in the way of keeping
up with mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=703443
Currently we "only" grab the keyboard when starting a drag operation,
which does not impede keybindings to be processed. This is at best
not harmful (like workspace switching), but may have unintended effects
otherwise - for instance, the hot corner is disabled, so having the
corresponding keyboard shortcut still active is fairly odd (not to
mention that it leaves the system in a confused state).
Fix this by switching to pushModal()/popModal(), which will push a
dedicated keybinding mode for us.
https://bugzilla.gnome.org/show_bug.cgi?id=700877
The actor is the same as the drag actor in this case, but we tend to
set properties on the drag actor and get them from the actor elsewhere
in this codepath. Make this consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=697504
This happens in the case of Workspace/WorkspaceThumbnail: they call
meta_window_change_workspace_by_index(), which fires window-removed
on the old workspace, thus destroying the window clone.
https://bugzilla.gnome.org/show_bug.cgi?id=685285
PopupMenuManager eats the next release event, which would otherwise close
the menu, so we need to tell dnd that we're handling it, and no drag should
be started, so it can ungrab the pointer and restore state.
https://bugzilla.gnome.org/show_bug.cgi?id=694276
To avoid messing up St.Buttons' internal state with a pointer grab,
we wait for the pointer to leave the actor before starting the
drag operation manually. This works generally fine, but makes starting
a drag operation harder than necessary. To fix, enforce a reasonable
button state when starting the drag, rather than special-casing buttons
before the drag.
https://bugzilla.gnome.org/show_bug.cgi?id=637103
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
