If the AllView is scrolled, the vertical scrollbar will take away
some horizontal space on one side, resulting in the content ending
up slightly off-center.
Account for this by using overlay-scrollbars instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
If enabled, scrollbars take away from the allocation given to the
view's content. This is usually preferrable to painting the bars on
top of the content, but there are exceptions, for instance when the
content needs to be centered with regard to the view as a whole.
Add a :overlay-scrollbars property to account for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
The frequent view should not be scrolled, but to work around the
icon grid overflowing, we used a (non-scrolling) scroll view anyway.
Now that IconGrid:fillParent allows us to avoid overflow, we can
remove this hack.
https://bugzilla.gnome.org/show_bug.cgi?id=694256
We sometimes map the stage before we've loaded a background on it
because of a race asynchronously loading the session mode.
This manifests as the startup animating starting over a white
background.
This commit defers showing the stage until after the still frames
are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
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
When the user clicks on "View Source" or "Web Page" in the "Extensions" tab of
looking glass, the callback _onViewSource() or _onWebPage() is called and they
try to close looking glass: this._lookingGlass.close();
But it does not work and generate the exception "this._lookingGlass is
undefined". This patch fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=693814
animateIn and animateOut should not reset the scale, otherwise
extra animate calls (which are possible because the diff algorithm
in _redisplay is not optimal) cause unneeded movement.
Therefore, create new items hidden, and have the creator call
animateIn or set the scale/opacity properties manually.
adjustIconSize must be changed to always set the icon size temporarily,
otherwise the first time it computes the icon size with 0 scale.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
The DashActor will known to allocate the show apps button only if the
icon size is (temporarily) too big for the containing box, therefore
it should request just that as the minimum size.
This solves a glitch that happened when removing a favorite and at the
same time causing the dash to expand.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
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
Using the scroll wheel to switch workspaces makes sense, but it is
currently only supported on the workspace switcher, as it conflicts
with window zooming in the picker.
As changing workspaces is far more useful than the zoom feature,
remove the latter in order to "free" the scroll wheel for workspace
switching.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
Right now if a user logs out, they are thrown to the login screen
imediately, without even seeing the dialog close.
This commit fades the dialog out before processing the logout.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Opening and closing a modal dialog is not instant. There
is a transition animation involved. When the dialog is
finished opening, it currently emits the "opened" signal.
When it's finished closing, however, it doesn't emit a
"closed" signal. This means, there's not a good way to
know when the dialog finishes closing.
This commit adds the "closed" signal.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Modal dialogs take an optional timestamp in their close method.
If the timestamp is not passed in, then global.get_current_time()
is used.
Some callers of the close method pass in global.get_current_time()
unnecessarly (since it's the default).
This commit drops the argument for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
And reverse menu order in order to avoid it reading "Change Background… Settings"
"System Settings" shouldn't be used because it's not used to mean the control-center in any other place.
https://bugzilla.gnome.org/show_bug.cgi?id=694290
We disable the entry after a user answers a question while we
process it, but we don't reactivate it later if asked another
one.
This commit makes sure the entry is always reactive when we
are waiting for an answer from the user.
https://bugzilla.gnome.org/show_bug.cgi?id=691806
When a swipe scroll completes, we scroll the active workspace into
view. This works fine if the gesture is completed properly by
emitting 'gesture-end', but not when Clutter considers the gesture
cancelled - in that case, the view remains stuck in an intermediate
position. To fix, treat 'gesture-cancel' the same as 'gesture-end'.
https://bugzilla.gnome.org/show_bug.cgi?id=689394
This means that windows will be positioned correctly with respect
to the panel when the shell starts up, and there won't be adjusting
after the session animation zooms in entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Due to a bad rebase causing freezeUpdateCount to never get initialized,
these functions effectively did nothing. Since we're going to go to a
different mechanism for freezing region updates, let's just tear these
out now instead of fixing them before tearing them out.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
PopupMenuManager eats the next release event, which would otherwise close
the menu, so we need to tell dnd that we're handling it, and no drag should
be started, so it can ungrab the pointer and restore state.
https://bugzilla.gnome.org/show_bug.cgi?id=694276
The arrow origin must be in the coordinate space of the box pointer,
but it cannot be calculated when the box pointer is shown, because it's
not allocated yet, so pass the source to the boxpointer and adjust
the arrow at the next paint.
https://bugzilla.gnome.org/show_bug.cgi?id=694264
St.Bin() really only expects one child at a time, and the
BackgroundManager will add two. This can cause assertion
failures when destroying one of the background actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
