Moving the mouse fast enough during xdnd will trigger a xdnd-leave event
because the input shape is not updated until after the animation is done.
So simply ignore the leave events while the animation is in progress.
https://bugzilla.gnome.org/show_bug.cgi?id=708887
This method, which accepts a .desktop filename, is used to highlight
a specific application in the overview, for example because it has
just been created or installed.
https://bugzilla.gnome.org/show_bug.cgi?id=654086
The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Instead of using the input mode, when the overview is not modal
it should use a Chrome-tracked actor, that is added to the input
region. Because the overview always takes pointer input when
visible, the actor is added at startup, and it is shown and hidden
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Some keyboard spot a dedicated search key, which gnome-settings-daemon
currently handles by spawning gnome-search-tool. It makes a lot of
sense to promote the Shell's integrated search feature instead, so
expose an appropriate DBus method g-s-d can use.
https://bugzilla.gnome.org/show_bug.cgi?id=700536
Instead of creating a bunch of random actors and then passing
them off to the controls manager, let the controls manager
construct them. This leaves the controls manager in charge
of the ordeal.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
Rather than expose a dizzying array of methods related to managing
state that require infecting every user of the overview methods, try
to do the sensible and smart thing internally. Now, the overview
itself tracks when XDND drags start, and simply calling show, hide or
toggle while an XDnD drag is in effect will show the overview, and
will only take the grab until after the XDND drag ends.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
This cleans up the code considerably, and makes it so that
one path creates all hot corners for all monitors. Why this
wasn't done originally, I have no clue...
The one complication is debouncing if the button and hot corner
are triggered in rapid succession, so we just move this tracking
to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
Previously, the overview BoxLayout was sized and positioned explicitly
using the primary monitor coordinates, as its parent was at 0,0 and
with a fixed layout manager. Now we use a bin layout, so we need to
position and size the stack actor, and set the overview boxlayout to
expand.
Take also the occasion to use a MonitorConstraint instead of handling
position and size manually.
https://bugzilla.gnome.org/show_bug.cgi?id=694969
We used to clip the overview group to prevent the dash from sliding into
neighbor monitors, but now it moved to the groupStack, so we must move
the clip too.
https://bugzilla.gnome.org/show_bug.cgi?id=694970
We generally want view content centered, in particular where the
view itself is symmetrical. So move the dash to a separate layer
and use a placeholder to account for its size when showing the
window picker, which is the only view where it doesn't make sense
to center the content.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
Commit 43ed66cf26 changed the toplevel overview actor, so it
makes sense to change the show/hide transitions to use that instead
of the existing group, to avoid elements layered on top of the
group being excluded from the transitions.
It is useful at times to perform several actions that would usually
close the overview (for instance launching an application) at once.
Currently we allow this by dragging items to a workspace rather than
just clicking it, but it's an odd metaphor with its own set of
problems.
Introduce an alternative approach (inspired by file selection in
file managers) by keeping the overview open if a Control key is
held down.
https://bugzilla.gnome.org/show_bug.cgi?id=686984
Using the scroll wheel in the window picker should switch workspaces.
As the picker doesn't have a visible boundary though, it makes sense
to accept scroll-event for the entire overview area. Rather than
making the overview's main actor public, expose scroll-events via
a signal.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
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
All the complexity with a custom actor and a generic container was
just to add some padding below the overview controls. Remove that,
and use CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694100
Account for the search entry space at the bottom (the former message
tray clone) individually in each side control, instead of packing
another actor in the overview.
This allows us to extend the central view all the way to the bottom,
while still keeping controls centered vertically.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
And use it in overviewControls. When we moved this code from overview.js
to overviewControls.js we lost a condition so we now slide in controls
even when going back from the overview, which looks bad.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
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
Adjust the layout of the overview and window thumbnails to make them
bigger. Also, make the background shade darker to compensate for the
increased thumbnail density.
https://bugzilla.gnome.org/show_bug.cgi?id=689876
The message tray actor also includes notifications themselves. We want
our ghost to be sized as the base part of the tray instead.
Just make sure to use the same style class as the base actor then, as
its height is specified by the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
When pressing the overlay key three times, things went like this:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* show(), push a modal
Thus, when the showing is done, and then it activated the hiding,
it popped one modal, but not the other. This patch changes things
to be:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* hide(), no-op
That is, mashing the overlay-key when it's showing will always make
it hide, not mashing an odd number of times.
https://bugzilla.gnome.org/show_bug.cgi?id=688589
Currently we assume that either the initial sessionMode will have
the overview or none of the pushed modes - starting without the
overview and pushing a mode that adds it fails spectacularly.
However this is exactly what we are going to do when loading external
modes asynchronously - we'll initially use the default mode while
the modes are loading, and switch to the mode passed on the command
line when finished. So make sure that the overview UI gets initialized
properly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
