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
Just as we did for the workspace switcher popup, support workspaces
being laid out in a single row in the window picker.
Note that this takes care of the various workspace switch actions in
the overview (scrolling, panning, touch(pad) gestures) as well as the
switch animation, but not of the overview's workspace switcher component.
There are currently no plans to support other layouts there, as the
component is inherently vertical (in fact, it was the whole reason for
switching the layout in the first place).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/575
For some reason, people are still seeing those after commit d5ebd8c8.
While this is something we really should figure out, we can work around
the issue by keeping the view actors hidden until the update is complete.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1065
At the point it is disabled, it has got signal handlers connected but
this._workspacesView is uninitialized. This triggers:
(gnome-shell:3993): Gjs-WARNING **: 18:49:53.281: JS ERROR: Exception in callback for signal: cancel: TypeError: this._workspacesViews is undefined
_endTouchGesture@resource:///org/gnome/shell/ui/workspacesView.js:527:25
_emit@resource:///org/gnome/gjs/modules/signals.js:142:27
set enabled@resource:///org/gnome/shell/ui/windowManager.js:478:13
WorkspacesDisplay<@resource:///org/gnome/shell/ui/workspacesView.js:482:9
ViewSelector<@resource:///org/gnome/shell/ui/viewSelector.js:167:35
ControlsManager<@resource:///org/gnome/shell/ui/overviewControls.js:405:29
init@resource:///org/gnome/shell/ui/overview.js:234:26
_initializeUI@resource:///org/gnome/shell/ui/main.js:184:5
start@resource:///org/gnome/shell/ui/main.js:124:5
@<main>:1:31
On startup. Shuffling these two lines prevent this from happening.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/506
Now that the existing touch/touchpad gestures in windowManager only
handle normal mode, add corresponding gestures for the overview and
hook them up to the existing workspace scroll animations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
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
This attribute was previously only assigned in show(). hide() compares
this attribute to 0. If hide() is called before show() is first called,
the comparison would give the correct result (undefined > 0 is false)
but log a warning:
JS WARNING: [resource:///org/gnome/shell/ui/workspacesView.js 529]:
reference to undefined property "_restackedNotifyId"
Initialize this attribute in _init(), alongside _scrollEventId and
_keyPressEventId which are also used in hide().
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
It is odd to switch workspaces on the primary monitor when panning on
a monitor without workspaces, so reject the gesture on non-primary
monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
It is odd to switch workspaces using the scroll wheel when the pointer
is on a monitor without workspaces, so only handle scroll events on
non-primary monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
We allow activating a workspace by clicking it when we know that
the user did not try to select a window and missed (namely: the
workspace is empty). However we currently always check for an
empty workspace on the primary monitor, which doesn't make sense
when the click happened on a different monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Initializing the upper bound to zero means that on panning we'd start
scrolling from the first workspace even if the current workspace when
entering the overview was different since StAdjustment clamps the
value to be inside bounds.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
This works for pointers and touch on X11, there is however no pointer
emulation on evdev, so touch triggers ::clicked with button==0 which
is ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
To switch workspace by keyboard in the overview, the user currently
has to use the normal keybinding. However as the vertical alignment
of workspaces makes them very similar to pages in the app picker, it
makes sense to also support the standard pageUp/pageDown keys.
https://bugzilla.gnome.org/show_bug.cgi?id=742581
It is quite weird to have those calls/signals using WindowClone as an
argument, it is neater to pass MetaWindows around, and have each user
deal with their own representations of these.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
And use it to lookup the local WindowClone that applies. Otherwise,
WorkspaceThumbnail.WindowClone objects may be mistakenly set, which
are not usable interchangeably with Workspace.WindowClone ones. This
may lead to several misbehaviors as fields available in the second
object but not in the first one are accessed, some those undefined
values get used in math ops, which result in NaNs over the place.
Likewise, the similar functions in WorkspacesViewBase subclasses take
now MetaWindow arguments too.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
The zooming animation of the windows looks nice when animating
from the workspace display page, but looks weird from other pages
like apps page or search page since the windows come from nowhere
with an initial position not known to the user.
Instead of that just fade the desktop with the windows in its
original position.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
They are different properties, they deserve different syncs.
Especially because a full allocation cycle sets both anyway, so
we should save some cycles this way.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
By default, gesture actions no longer wait for the dnd threshold to
be reached before triggering, which breaks our mixing of click- and
pan actions. Fix this by only panning after reaching the threshold
and letting the click action go through if the pan is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=722417
Workspaces can removed from any index, and in particular they
will be removed by the WorkspaceTracker if they stop containing
windows at some point. Make sure WorkspacesView is not confused
and destroyes the right Workspace objects.
https://bugzilla.gnome.org/show_bug.cgi?id=721417
Simply use St's existing key navigation system by making all the window
clones StWidgets, and making the WorkspacesView a focus group.
Since the workspace view is effectively "fake", we need to add a focus
delegator so that when key focus is assigned to the fake workspaces page,
we can keynav inside it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
Before, workspacesOnlyOnPrimary was implemented in quite a crazy manner:
* If workspacesOnlyOnPrimary was false, we'd create one WorkspacesView per
monitor, with the primary one being a bit special.
* If workspacesOnlyOnPrimary was true, we'd create one WorkspacesView, and
additional montiors would be handled inside that WorkspacesView as
"extra workspaces".
This caused numerous bugs as the two modes weren't consistently
implemented, and a lot of code was duplicated between all the modes.
Fix this by always creating WorkspaceViews, even if it only handles
one interface. We do this by having two different WorkspacesView-ish
classes: WorkspacesView handles the traditional combination of lots
of workspces, and a new ExtraWorkspaceView is in control of only one
workspace.
Right now, the workspace update code is complex and spread across parts:
WorkspacesView takes a set of workspaces and looks like it owns them, but
WorkspacesDisplay is actually in charge of setting them up and creating
new ones for each WorkspacesView.
Change initialization and handling to move all of the creation/destruction
responsibilities to WorkspacesView.
We pass in monitorIndex into each WorkspacesView, which is a lie in the
workspacesOnlyOnPrimary case, as the primary WorkspacesView currently has
the responsibility of handling the extra workspaces on all the other
monitors. The commit will clean this up and punt the responsibility back
to WorkspacesDisplay.
