The rewrite of Mutter's background code (see bug 735637) requires
corresponding changes here - we no longer need to layer multiple
MetaBackgroundActors together.
The general strategy is that a BackgroundSource object is created
per GSettings schema, and keeps either one Background/MetaBackground pair,
or, for animation, a Background/Metabackground pair for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=735638
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
The slide of thumbnailWorkspace is shown when entering overview,
connecting to the same signal that creates the thumbnails, the showing
signal of overview, but, to make the slide animation we need to know how
much width the slider has. To do that we ask the thumbnailsWorkspace
about its width, but given that it connects to the same signal it could
ask the width without having created the thumbnails yet, so reporting a
width of 0 and confusing the slide animation.
Currently it works because gjs calls the callbacks following the order
of the clients connecting that signal, and the thumbnailsWorskpace is
connected before the slide ones.
To avoid that we allow to request the preferred size of the
thumbnailsBox at any time with any number of thumbnails. The only thing
required is to make sure the porthole is accessible when requesting the
preferred size.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
When dragging a window preview from a non-primary monitor onto a
workspace thumbnail, the window is moved to the primery monitor
first before changing its workspace. However when dragging the window
between thumbnails to create a new workspace, it is kept on its current
monitor instead. This is not only inconsistent, but outright confusing
with the default 'workspaces-only-on-primary' setting, as the newly
created workspace is immediately removed again.
https://bugzilla.gnome.org/show_bug.cgi?id=683819
When workspaces have been removed, we need to remove the corresponding
thumbnails as well; the number of thumbnails that need removing is
the difference between the old number of workspaces and the new one.
Currently we assume that the old number of workspaces corresponds to
the number of existing thumbnails, but that may actually be wrong:
A thumbnail will still be animated out after its workspace has been
removed. As a result, we end up removing too many thumbnails when a
workspace is removed while a thumbnail of a previously removed workspace
is still animating out. Fix this by basing the old number of workspaces
only on thumbnails that have not been removed previously.
https://bugzilla.gnome.org/show_bug.cgi?id=728820
Commit 61a58ff3c9 replaced the (removed in commit 254afc50223a7)
MetaWindowActor.get_workspace() method by MetaWindow.get_workspace(),
but did not take into account that the return values differ - the
former returns the workspace index, the latter the workspace object.
https://bugzilla.gnome.org/show_bug.cgi?id=724686
The window clones in the central part of the overview are showing modal
dialogs now, and this creates an inconsistency if the thumbnail doesn't too.
Code is intentionally similar in the two places.
https://bugzilla.gnome.org/show_bug.cgi?id=650843
The _background hack was added because the old way the zooming animation
worked, it set the allocation of the workspaces view and thumbnails box
to the final position and used animations to smoothly animate.
During the 3.6 cycle when we added the new search view, Cosimo changed the
way the zoom animation works so that rather than set the final allocation
and animate, we actually do adjust the allocation of the workspaces view
and thumbnails box.
So, as the hack is no longer necessary, we can drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
When we shift workspaces to create a blank one for a window or
application, all of the window actors are shifted down. However, some
of these window actors are transient windows attached to a main window.
When these windows are moved to a different workspace, the main window
is moved along with it. When the main window is moved, these windows
are also moved. This creates a double move of the windows.
This double movement leads to unexpected results where workspaces are
collapsed and windows are in incorrect positions.
This patch prevents movement of these transient windows, only grabbing
the main (ancestor) windows to move to a different workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=705174
Right now we only destroy the bgManager object when the
workspaceThumbnail is explicitly destroy with its destroy()
method.
This commit makes sure bgManager gets destroyed when the
workspaceThumbnail actor is destroyed without calling
destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=696157
To create a new workspace by dropping on the placeholder, we move all
the windows down one workspace and then wait for _checkWorkspaces() to
automatically create the empty one at the end.
This means that, from the implementation POV, the new workspace is not
the one created by DND but it's the last one, and this detail was exposed
in the UI because the animation was applied on that one.
Fix that by starting the animation manually from the DND code, and then
blocking the animation from happening when the new workspace is created
with a flag.
https://bugzilla.gnome.org/show_bug.cgi?id=685285
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 commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.
Based on initial work by Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=682429
Both WorkspacesDisplay and ThumbnailsBox need to know when windows have been
restacked. Instead of each tracking changes on their own or trying to call
each other, have the overview keep track and do the calculations, emitting
a signal with the result.
https://bugzilla.gnome.org/show_bug.cgi?id=690175
When in the overview, if you move the mouse cursor over one of the
application launchers in the dash, all the unrelated windows are dimmed
both both in the window view and in the workspace view.
It helps to easily understand whether or not there are already opened
windows for this application, and where they are. It can also help in
differentiating the windows in the overview (sometimes the thumbnails
aren't precise enough to easily know which thumbnail belongs to which
application).
https://bugzilla.gnome.org/show_bug.cgi?id=657315
This makes the workspace indicator respect the "padding" style attribute.
Also, since we no longer draw the border on top of the thumbnail,
we need to be pixel-precise in allocating the indicator height.
We use this to make the workspace selector more similar to the mockup.
https://bugzilla.gnome.org/show_bug.cgi?id=662087
Currently, click and drop events are handled by each WorkspaceThumbnail
instance. With the introduction of the workspace cut and the request
to extend the reactive area of the workspace selector to the edge
of the monitor, it becomes more convenient to do all the event handling
inside ThumbnailsBox, even if this requires some manual layout computation.
https://bugzilla.gnome.org/show_bug.cgi?id=643319
In the workspace-collecting code we add a check to avoid collecting a
workspace if any startup sequence is running there. Since the sequence
can take some time to load, an helper function is also added which keeps
the (empty) workspace around for a very short time, while waiting for the
sequence to start.
https://bugzilla.gnome.org/show_bug.cgi?id=664202
The dynamic-workspaces key was introduced to allow us to opt out of
writing the num-workspaces setting (which is ignored with the dynamic
workspace management anyway), but there'll be some expectations that
the setting will have an effect on the UI.
It's actually not very hard to support, so here's to the graybeards ...
https://bugzilla.gnome.org/show_bug.cgi?id=671568
