Commit Graph

201 Commits

Author SHA1 Message Date
Florian Müllner
ff29159df2 workspaceThumbnail: Use new helper function when accepting drops
Moving a window from a secondary monitor to a non-active workspace
currently fails for the aforementioned reasons.

Use the newly added helper function to address this.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/893

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2259>
2022-03-31 17:56:49 +02:00
Jonas Ådahl
b3c7a855c6 workspaceThumbnail: Use transient object for connecting some signals
We want to connect and disconnect a bunch of signals when showing/hiding
the worskpace thumbnails. To make this easy, use a transient object that
we tie to these signal handlers.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2220>
2022-03-05 10:08:48 +01:00
Florian Müllner
69717424f7 workspaceThumbnail: Remove unused properties
Those aren't used anymore since the switch to connectObject().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2222>
2022-03-05 00:38:05 +01:00
Florian Müllner
26235bbe54 js: Use (dis)connectObject()
Start using the new methods to simplify signal cleanup. For now,
focus on replacing existing cleanups; in most cases this means
signals connected in the constructor and disconnected on destroy,
but also other cases with a similarly defined lifetime (say: from
show to hide).

This doesn't change signal connections that only exist for a short
time (say: once), handlers that are connected on-demand (say: the
first time a particular method is called), or connections that
aren't tracked (read: disconnected) at all.

We will eventually replace the latter with connectObject() as
well - especially from actor subclasses - but the changeset is
already big enough as-is :-)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
2022-03-04 14:14:37 +00:00
Florian Müllner
2b45a01517 cleanup: Use new indentation style for object literals
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.

But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).

And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
2022-02-23 12:23:52 +00:00
Georges Basile Stavracas Neto
e9119c625d workspaceThumbnail: Destroy thumbnails on destruction
Often, when using multiple monitors, the thumbnails box may be
destroyed before the 'hidden' signal of the Overview is emitted,
which leaves a bunch of lingering signal connections to the
workspace manager.

Call this._destroyThumbnails() in the _onDestroy handler, which
disconnects from workspace manager. This fixes the some of the log
spam that GNOME Shell produces with backtraces of destroyed actors.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1860>
2021-05-25 12:43:32 -03:00
Sebastian Keller
0e917c3dbf workspaceThumbnail: Only create thumbnails once
`ThumbnailsBox` listens for the `showing` signal from the `Overview` to
create its thumbnails and destroys them on the `hide` signal. Since the
`showing` signal can be emitted multiple times when switching between
the shown and hidden state without ever fully completing the transition,
this will cause `_createThumbnails` to be called multiple times, each
time adding another set of workspaces.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
2021-04-29 17:58:45 +00:00
Jonas Ådahl
1f0ef7fb46 workspaceThumbnail: Update monitor index on 'monitors-changed'
For the primary monitor workspace thumbnail, we must keep the monitor
index in sync with what is currently the primary monitor index,
otherwise we might end up trying to move windows to non-existing
monitors.

For example, if the primary monitor index was 1 when the thumbnail box
was created, but later, the primary monitor index changed to 0, with the
other monitor being turned off, moving a window to one of the workspaces
on the workspace thumbnail, gnome-shell would attempt to move it to the
monitor with the index the primary monitor had in the past, with the
problem being that that monitor no longer exists.

Fix this by listening on the 'monitors-changed' signal on the layout
manager, and update the monitor index of the primary workspace
thumbnails box. Make sure to connect to the signal before creating the
thumbnails box, as the thumbnails box itself will listen to the signal
and recreate its actual thumbnails, and it must do this with the up to
date monitor index.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1810>
2021-04-14 15:43:09 +00:00
Jonas Dreßler
7a57528bd7 workspaceThumbnail: Update visibility when showing the overview
There's currently a bug that we continue showing the workspace minimap
when the number of workspaces changes back to 1 during the session (ie.
outside the overview). Fix that by also updating the workspaceThumbnails
visibility when entering the overview.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1741>
2021-03-04 12:39:37 +00:00
Florian Müllner
30f0c9f943 workspaceThumbnails: Update indicator on workspace changes
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.

To fix that, update the indicator on workspace changes as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Florian Müllner
fac50fb50e workspaceThumbnail: Queue state update after expanding
New workspaces are added in two steps, first the minimap expands to make
room for the new thumbnail, then the thumbnail animates in. However we
currently don't queue a state update after the first step, so the second
one only happens after one is queued by some other event (like a workspace
switch).

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3748

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Florian Müllner
2731d35723 workspaceThumbnails: Pass monitor index to constructor
We'll soon add workspace thumbnails on secondary monitors as well,
so set the monitor explicitly instead of assuming the primary one.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
4eb31e4e18 workspaceThumbnails: Immediately initialize should-show
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
09afaf0745 workspaceThumbnail: Initialize porthole to work area
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.

That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
945e947a54 workspaceThumbnails: Disconnect signals on destroy
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
49b7973177 workspaceThumbnail: Consider porthole offsets
Since commit 9980c80619, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).

To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.

The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3781

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1721>
2021-02-26 14:36:39 +01:00
Florian Müllner
2fdee8e444 workspaceThumbnails: Only show for more than two workspaces
As adjacent workspaces now peek into the window picker, the first
two workspaces are already accessible without the minimap. Hide
it in that case to give more space to the window picker, and to
not clutter the overview for users who aren't using workspaces.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
d3a1557864 workspaceThumbnail: Do not update scale while collapsing
The scale property tracks the relative size at which we display thumbnails
given the space we have available.

That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.

Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
7b1b04f95a workspaceThumbnails: Delay workspace removal while collapsing
Animating a thumbnail removal while also collapsing the minimap
itself doesn't look good, so keep the stale thumbnail until the
minimap is hidden.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
a2751a1b26 workspaceThumbnails: Don't animate thumbnail additions while hidden
This is not just an obvious mini-optimization, it also ensures that we
don't start showing the minimap with an ongoing thumbnail transition.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
a73bea02e8 workspaceThumbnails: Animate showing/hiding
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.

However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.

Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:02 +01:00
Florian Müllner
f239179682 workspaceThumnails: Add :should-show property
We currently have two components that show or hide the minimap:

 - the thumbnails hide themselves in case of a single static workspace
 - overview controls show the minimap when no search is active

That obviously doesn't work correctly.

To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Florian Müllner
bf8e762178 workspaceThumbnail: Base n-workspaces on number of thumbs
It's what we base our size request on, and what we actually allocate.
The difference usually doesn't matter right now, but will soon when
we animate the minimap itself.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Florian Müllner
2e9715c97e workspaceThumbnails: Actually use vscale parameter
We pass two scales to setScale(), but only use the first one for
both horizontal and vertical scaling. We'll soon have a use case
for using a different scale for each dimension, so start using
both parameters.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Florian Müllner
252f2f5144 cleanup: Define GObject accessors in camelCase
gjs is smart enough to match a propertyName getter/setter to the
corresponding property-name GObject property, so use that and get
rid of the eslint camelcase rule exceptions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
a41e294e21 workspaceThumbnails: Remove obsolete property
Since commit f55ff01239, the property has been replaced by
an adjustment.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
de299f0a90 workspaceThumbnails: Center thumbnails in workspace navigator
We always request a natural width based on the maximum thumbnail scale,
but may very well use a smaller scale when allocating. This currently
results in thumbnails being off center, fix this by distributing any
extra space evenly before allocating thumbnails.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1620>
2021-02-01 16:34:37 +01:00
Florian Müllner
b84eb2437d workspaceThumbnails: Expand workspaces before scale-in animation
When the original animation was implemented, workspaces would only
ever be added at the end. We therefore got away with not having a
separate EXPANDING stage corresponding to the existing COLLAPSING
one when animating out.

Since support for creating in-between workspaces via DND was added,
this is no longer the case. And now that the thumbnails are centered,
the jump is quite noticeable.

Address this by adding new transitional states, so that we can
expand new thumbnails before scaling them in.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1609>
2021-01-29 17:55:44 +01:00
Georges Basile Stavracas Neto
9db9445b0f workspaceThumbnail: Scale workspaces in and out
Make the slide property control the workspace scale, so that new workspaces
scale up, and destroyed workspaces scale down. The scale is done horizontally,
and only slightly vertically, as per design direction.

Rework the state tracking mechanism to remove the COLLAPSING state, since there's
no split between sliding out and collapsing anymore. Also remove the corresponding
'collapse-fraction' property from WorkspaceThumbnail.

Make ThumbnailsBox.vfunc_get_preferred_width() consider the slide-position property.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
df2181c913 workspaceThumbnail: Use current number of workspaces for sizes
There are situations where MetaWorkspaceManager and ThumbnailsBox disagree
on the number of workspaces, for example when animating them out. It's more
important to follow the visible number of workspaces while they're updated.

Make vfunc_get_preferred_width() and vfunc_get_preferred_height() use the
current number of workspace thumbnails to calculate their sizes, instead of
MetaWorkspaceManager's n-thumbnails property.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
d368bae503 workspaceThumbnail/thumbnailsBox: Set pivot point
Set the pivot point at the center of the ThumbnailsBox so that scaling
in and out looks better.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
451ba5b03a workspaceThumbnail: Remove wallpaper
They'll be replaced by a stylized background color to make them look
symbolic.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
0d4bce9fa7 workspaceThumbnail: Reduce maximum scale to 5%
As per design direction, reduce the maximum workspaces thumbnails to 5% of the
primary monitor size.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
9980c80619 workspaceThumbnail: Allocate final thumbnail sizes
ThumbnailsBox currently allocates each workspace thumbnail using their
porthole size, and scales them down using scale-x and scale-y. This is
slightly problematic since it doesn't allow for properly styling these
thumbnails through CSS.

Rework ThumbnailsBox to allocate workspace thumbnails at their actual
sizes, and scale down the '_contents' actor inside WorkspaceThumbnail.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
3ad7b85e25 workspaceThumbnail: Make it horizontal
Allocate workspace thumbnails horizontally. This requires introducing code
to handle the RTL direction. Do a small rewrite of the DnD hover method to
be simultaneously simpler and easier to follow, and work correctly on RTL.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
f17d9676f8 overviewControls: Move workspaces thumbnails to ViewSelector
This is now all centralized in the apps page, so move the workspaces
thumbnails to ViewSelector's apps page. This allows us to remove
all the slider controls too, since they're now unused.

The transition between showing the workspaces, and the app grid, is
based on the most recent mockups: scale and move it down, and fade it
out.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Jonas Dreßler
3fb0284358 Make sure to allocate all children in allocate vfuncs
Clutter expects actors overriding the allocate vfunc to allocate all
mapped children of the actor, otherwise bad things happen.

So make sure we actually allocate all our visible children in our custom
allocation functions, and since we don't want to give them a real
allocation, just pass them an empty ClutterActorBox.

It would be nice if we had a way to hide children during the allocation
process where no relayout is queued like gtk allows with
gtk_widget_set_child_visible(), then we could avoid those weird empty
ClutterActorBoxes.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3098

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1481>
2020-11-24 20:20:45 +00:00
Florian Müllner
e90466347a cleanup: Use Meta.Workspace.active property
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1337
2020-06-29 17:09:38 +02:00
Jonas Dreßler
46600740fe workspace: Stop using WindowPreview.realWindow in the overview
We can simply get the MetaWindowActor by calling
MetaWindow.get_compositor_private(), so stop accessing the realWindow
property of WindowPreview. For this we also have to make _isMyWindow()
and _isOverviewWindow() take a MetaWindow as an argument instead of a
MetaWindowActor.

Since the WorkspacesThumbnails are also drop targets for WindowPreviews
and their WindowClones also have the public metaWindow property, switch
to using the metaWindow property there, too.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:10:01 +02:00
Jonas Dreßler
9b99b67fea Remove ClutterAllocationFlags
Those flags were removed from Clutter since they're pretty much unused,
so remove them here, too.

See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1245
2020-05-20 15:12:03 +02:00
Alexander Mikhaylenko
9c1940ef9d workspaceThumbnail: Sync indicator with WorkspacesDisplay
Now that both ThumbnailsBox and WorkspacesDisplay use single adjustments for
controlling indicator and scrolling, create the adjustment in OverviewControls
and pass it to both objects, effectively syncing indicator to scrolling.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
2020-01-08 23:07:08 +01:00
Alexander Mikhaylenko
f55ff01239 workspaceThumbnail: Use scroll adjustment
This will allow it to share adjustment with WorkspacesDisplay in the next
commit.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/821
2020-01-08 23:07:08 +01:00
Florian Müllner
e44adb92cf cleanup: Avoid unnecessary parentheses
Extra parentheses usually add noise rather than clarity, so avoid
them.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
ebf77748a8 cleanup: Require "dangling" commas
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
2019-11-11 19:25:14 +00:00
Florian Müllner
07cc84f632 cleanup: Only omit braces for single-line blocks
Braces can be avoided when a block consists of a single statement,
but readability suffers when the statement spans more than a single
line.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
9eaa0089d0 cleanup: Fix missing/stray spaces
Those are wrong according to our style guidelines, but the previous
eslint ruleset didn't catch them.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
682bd7e97c cleanup: Don't shadow variables
Having variables that share the same name in overlapping scopes is
confusing and error-prone, and is best avoided.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
67ea424525 cleanup: Avoid unnecessary braces
Our coding style has always been to avoid braces when all blocks
are single-lines.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
1e203f4631 cleanup: Replace deprecated lower/raise calls
Those methods have been deprecated for a long time, so
move to the drop-in replacement.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/808
2019-11-06 09:42:57 +01:00
Marco Trevisan (Treviño)
39e6fc9e9d js: Use Gjs GTypeName computation for all classes
As per previous commit we can remove the explicit GTypeName definitions
and use gjs auto computation for all the GObject registered classes.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/790
2019-10-29 18:38:35 +00:00