When accessing properties on ClutterActor for size and position there is
a notable access time overhead. This overhead adds considerable user lag
when opening the overview if many windows are open.
This is primarily due to these properties being accessed while sorting
WindowClone instances by their window's center for placement in the
overview. By pre-computing this center value only once when
initializing WindowClone, the induced lag can be significantly reduced.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/763
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
While commit 3094f863 was intended to cancel the ongoing idle hide
timeout before we start a new one, a mistake slipped in there while
rebasing: Obviously we should check if the signal id is NOT 0 here.
This didn't prevent timeouts being started while old ones are still
running and did override `this._idleHideOverlayId`, which caused the old
timeouts to run indefinitely after an overlay actor was destroyed
because we fail early (and don't return TRUE) in `_idleHideOverlay()`.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/735
Indicate whether dropping an app icon was successful or not by using the
newly added `animateLaunchAtPos()` API of AppIcon which starts a zoom
out animation of the icon at the position the drop happened.
To get the position of the drag actor, we have to forward the arguments
passed to `acceptDrop()` and `handleDragOver()` to the internal drag
handlers of the WorkspaceThumbnails. We can use this position directly
without transforming it to stage coordinates because the actor is a
child of `Main.uiGroup` and the animation actor will also be a child of
this container.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
Return the results of calls to acceptDrop that we forwarded to the
Workspace object.
This fixes a bug where app icons that were dragged and released above a
window clone would get animated back to their original position
(indicating that nothing happened) even though they opened correctly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
`AppIcon.shellWorkspaceLaunch()` can easily be replaced by checking for
`AppIcon.app` and calling `AppIcon.app.open_new_window()` directly.
For compatibility and to prevent breaking extensions implementing the
function, keep supporting the `shellWorkspaceLaunch` API in AppIcon
while logging a deprecation warning. Also keep supporting the API on
drag sources (without deprecating it) to allow extensions to define
custom actions on their drag sources.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
Instead of returning and waiting until the old timeout is finished,
start a new idle hide timeout for the overlay when the pointer enters a
window clone. This makes sure the timeout for hiding the overlay after
the pointer left the clone mostly stays the same (except when leaving
the clone via the title or the close button).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/683
Code and comment were based on the old get_input_rect() and get_outer_rect()
method names that were changed to the more appropriate get_buffer_rect() and
get_frame_rect() a long time ago.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/713
When transitioning to or from the overview, windows travel
a certain distance between their real desktop position and
their place in the overview window grid. The less this travel
distance is, the smoother, more polished, and less jarring
the overall transition looks. This is why it makes sense to
try reordering and repositioning windows to minimize their
travel distance. That being said, there are other factors
that impact the quality of the overview layout, such as how
much the windows get scaled and what portion of the overall
available space they take up.
The existing code tries to minimize the travel distance by
sorting the windows in each row by their horizontal position.
There are, however, two problems with this implementation.
First, it compares the coordinates of windows' left edges as
opposed to their centers, which means it yields unexpected
results when a small window is positioned next to the left
edge of a large window. Second, it completely disregards
vertical coordinates, instead assigning windows to the grid
rows using their monotonically increasing window numbers,
effectively vertically sorting them by the order they were
created in.
This commit changes both vertical and horizontal ordering
to work based on the coordinates of the geometric centers
of the windows. That is to say, windows are first assigned
to grid rows based on the vertical coordinates of their
centers, and subsequently sorted inside each row based on
the horizontal coordinates of said centers. In my testing,
this leads to a much more intuitive and visually pleasing
window placement.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/267
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
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Window previews are sometimes shown translucent, for example during
drags or animations. They can also have attached dialogs, in which
case the opacity should affect the combination of all windows instead
of being applied to each window individually, blended together, so
make sure they are redirected as a whole when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/774
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a "virtual" method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/549
Since the overlays we show on hover above the window clones are no
longer only a close button, but the window title, a border and a close
button, rename a few variables so it's easier to understand what they're
for.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/346
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
When we started to only show a single caption at a time, we allowed
title captions to be wider than their corresponding window preview.
But while overlapping neighboring previews is fine, we shouldn't
allow the captions to leak outside the workspace area itself and
overlap unrelated elements like workspace switcher or dash.
This partly reverts commit b3b30f239d.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/214
When trying to close a window in the overview by clicking the close
button and the window doesn't get closed but a dialog is added to the
window afterwards, we close the overview and show the dialog.
Instead of adding a separate listener for the window-added signal to the
WindowOverlay, let the WindowClones remember that the close button was
pressed and activate themselves if a dialog is added after that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/180
When a dialog is added to a window while the overview is shown, we get
its parent using get_transient_for() so we can add it to the right
window clone.
If we have multiple layers of dialogs we have to do this recursively
until we find the root ancestor. This case currently results in an
infinite loop: Since parent is always set to the same window, the
while-condition will always be true.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/180
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
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
Just like we did for the window list in app icons' context menu,
provide a fallback for window captions in the window picker rather
than showing blank items to the user.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
Since commit 1939e22c22, we move the keyboard focus with the hover
highlight. However while this makes sense when interacting with
the window picker, it interferes with keyboard navigation of other
components like dash or top bar. Address this by only moving the
focus when the previous focus was already inside the window picker
or unset.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/50
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
We don't use different hover- and focus indications for window previews,
so using keyboard navigation after hovering a clone often has surprising
results when the previous focus window wasn't the selected one. Address
this by simply moving the keyboard focus with the highlight.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
By default the focus chain uses the same order as the list returned
by clutter_actor_get_children(), which corresponds to the z-order.
This doesn't work well in the window picker, where clones follow
the stacking of windows to ensure a correct overview transition,
but previews are laid out purely based on space efficiency. As
a result, the order in which window previews are navigated when
tabbing around is essentially random. Fix this by providing a
focus chain implementation that is based on the visual layout
of the previews rather than the stacking.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
Now that full-sized window previews are allowed again it makes sense to
align the window previews with the pixel grid to prevent unscaled
windows from looking blurry in the overview.
Currently the chrome layer decides itself which events on the window
clone should show or hide the chrome, which makes it harder to extent.
Instead, move the decision to the window clone by letting it emit
show/hide-chrome events when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Previews are currently limited to at most 70% of the actual window
size. This was done to indicate more clearly that the overview is
active and the window cannot be interacted with. However since then
other indications like the vignette effect have been added, so
artificially limiting the preview size doesn't look necessary anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Now that only one window title is visible at any time, it no longer
matters if a title extends into other window previews, so we can
always show the full title.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
While the new title position gives the previews more space, they now
overlay the content which may hide valuable information. Address this
by only revealing the title as additional information on hover, like
we do for other auxiliary elements.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We consider the window previews the primary way to identify a window,
so it makes sense to give them as much space as possible. So in order
to not have title captions take up too much vertical space, overlay
them on top of the preview borders.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
In case where a method- and property name overlap, using the method
is less unambiguous than I thought - mozjs52-based gjs will only see
the method, while mozjs38-based gjs will only see the property. We
are in luck though, and the real property name contains dashes that
allow us to refer to the property in a way that works for all gjs
versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
ClutterActor has both a has_pointer() method and a :has-pointer
property (that we represent as 'has_pointer'). So far gjs was
able to deal with the name overlap, but now trying to use the
property will instead test for the availability of the method.
Just avoid the conflict by switching to the method, which is
unambiguous.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
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
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
There were some source IDs that were not being reset to zero when
removing the associated sources, resulting on some critical errors
being dumped when _realRecalculateWindowPositions() got called
after that point, via _delayedWindowRepositioning().
Dragging and dropping app icons is expected to work anywhere over a
workspace, however overlaid elements are added to a separate hierarchy
and can thus block valid drop targets. This wasn't much of an issue
while we had just the window title, but since the addition of the
focus border, drops on window previews stopped working entirely.
Fix this by hiding all non-reactive overlay elements from picks.
https://bugzilla.gnome.org/show_bug.cgi?id=737166
Using a MetaWindowActor's shaped texture as the source for window
clones means that if there are further MetaSurfaceActor children
(e.g. a wayland client using sub-surfaces) they don't get cloned.
This obviously wasn't an issue until wayland clients introduced the
possibility of having multiple MetaSurfaceActors under a
MetaWindowActor but there's no fundamental reason we can't clone the
toplevel actor.
WorkspaceThumbnail.WindowClone is the one class that was already using
the MetaWindowActor instead of the texture although it seems to have
been an unintended change in commit
8b99617513.
https://bugzilla.gnome.org/show_bug.cgi?id=756715
draggable.startDrag() is called directly here (i.e. manualMode is not set),
we must keep track of the touch event and pass it to startDrag() then.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
The previous code was applying the per row scaling factor of the current
row to the cumulative sum of all previous rows when calculating the y
position of a row. This resulted in the row being shifted up so it would
overlap other windows when the previous rows were not using the same
scaling as the current one.
Also the previous code was not considering that the spacing does not get
scaled when calculating the scaling factor. This is wrong as well and
could result in the overview overlapping the workspace switcher in
situations with lots of windows open.
This fix gives each row the appropriate height according to its scaling
factor and then ensures that the grid remains vertically centered after
losing some of its height.
https://bugzilla.gnome.org/show_bug.cgi?id=744883
Turns out this makes interaction with the OSK or candidate popups
using a mouse basically impossible since they get dismissed when the
key focus is captured by a window in the overview.
This reverts commit aeb9f5775f.
https://bugzilla.gnome.org/show_bug.cgi?id=745245
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
Since mutter commit 527c53a2a0582eba, MetaWorkspace::window-removed
is emitted *before* MetaWindow:workspace is updated, so the test
whether the removed window should still be on the workspace in
question will always return true.
Assume the test is no longer necessary nowadays to fix this very
obvious regression.
https://bugzilla.gnome.org/show_bug.cgi?id=735608
Currently we are removing tweens of the button and border, but not from
the title. That causes the title to be in wrong positions sometimes when
dragging windows on the overview, given that the slider is moving and
therefore the windows + overlay are moving too.
To avoid that, remove tweens of the title as well.
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
When returning to the desktop from overview we always show the
workspaceDisplay, given that is which have the windows clones to allow
animations.
The problem becomes when previous that we were at some other
page, like Search or AppDisplay. The problem is that when showing the
workspaceDisplay the windows are repositioned. That's wanted except
when returning from overview, since that causes unwanted animations
of the windows.
To avoid that just not reposition the windows if leaving the overview.
We already have the width and height information cached in JS,
let's avoid going through gjs-gobject-clutter to retrieve them
again. As a plus, with normal properties the optimizer should
be able to generate better code.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
Windows in the overview should be like they appear in the workspace,
including modal dialogs that are attached above them.
In addition, hiding the dialogs in the overview causes a flash as
dialog appears at the end of the transition.
Based on a patch by Maxim Ermilov <zaspire@rambler.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=650843
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
Because of the animation and collision with relayout, the title of windows in overview may not appear, mainly
the first time we enter in overview
With an animation delay of 0.1s, you'll not see the difference
https://bugzilla.gnome.org/show_bug.cgi?id=709392
We added special code to sort each row in the overview so that
windows were less likely to cross lines, but the awkward control
flow meant that everything but the last row got sorted.
https://bugzilla.gnome.org/show_bug.cgi?id=707197
Commit 16fa186b63 attempted to fix the zoom animation problem
by throwing changes on the floor while the overview is animating. This has
the side effect that we might end up missing some positioning changes causes
windows to overlap the workspace thumbnails.
So revert those changes and fix it by simply by passing
WindowPositionFlags.ANIMATE during the overview animation.
This way the animation works as expected and we don't miss any position changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703105
Meta laters are invoked in reverse order of registration, so
having multiple laters propagating the geometry cause all but the
first one in the frame (which is usually wrong) to be ignored.
Instead, queue at most one later call, and use the last set geometry
in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=700853
If windows are removed or added, we shouldn't keep the old layout, as it's
not valid anymore. If windows are removed, this is especially bad, as the
rows contain references to the removed window objects, causing crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=698622
Instead of applying an additional scale factor to all the rows in the
layout, only do it for those rows that don't fit.
This avoids the visual distraction of resizing a row when there's no
need to.
Instead of doing an entire recalculation of window positions when
sliding the thumbnails box, simply recalculate the position and scale
with basic aspect ratio math. This also ensures that windows won't
miraculously swap positions, even if we reposition windows while the
thumbnails box is expanded.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
Split out the part that moves the window clones around from
the part that calculates the window clone positions, and rename
both methods so that the overall meaning is more clear.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
Repositioning will eventually be separated from recalculation
to accomodate two different geometries, so we'll need to do
the padding and area manipulation in two different areas.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
As we want to eventually track two geometries, we need to rename
our very plain "_x, _y, _width, _height". While we could just prefix
them, I think that stuffing them in an object makes more sense.
At the same time, make the variable and method name more descriptive
by adding such a prefix, as well as a bit of documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
This was saved so that doing something which called relayout
but only changed the area rectangle would simply be needed to
recompute window scaling parameters. With the new overview
relayout, the flow control changed, it turns out that the
current layout is always cleared. Remove this for now, and we'll
put in a different strategy for this.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
Windows can be restacked at any time, including when the stackAbove
property of the window clone is being dragged, and thus parented to
the uiGroup. To do stacking properly, we need to skip it for the duration
of the drag, and sync it again at the end (which is already done by
mutter because of the workspace change)
https://bugzilla.gnome.org/show_bug.cgi?id=685285
This can happen if you open two or three terminal windows, and then
open the overview -- they're not centered. The issue is that because
of the WINDOW_CLONE_MAXIMUM_SCALE clamping, the scale that is being
laid out is different from the scale that the layout was calculated
for.
Implement and document a hack-ish solution which simply keeps the
scale for the layout as originally calculated, but centers the
windows inside the cell.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
Multiplication is linear, so we can split this out as a separate
component. This will make it easier to think of it as an additional
per-window scaling factor, rather than tweaking the scale a bit,
which is more correct to the model.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
