Previously, we would create one StBin per monitor, but each was positioned
at 0,0 and sized as the screen, so they would overlap and draw the box shadows
on top of the other backgrounds.
Instead, we need to size appropriately the bin, and then we need to position
the actual MetaBacgroundActor at 0,0, so add a flag to BackgroundManager
for this.
Also, get rid of MetaBackgroundGroup, they do nothing because the screenshield
is not a descendant of the MetaWindowGroup and because the widget in between
blocks the propagation of the visible region. At the same time, use a
widget, not a bin, because StBin requires you to set .child, not call add_child().
https://bugzilla.gnome.org/show_bug.cgi?id=694394
We recently started to trim leading and trailing whitespace from
the search string, and not to trigger a search when the resulting
string was empty. However we still allow whitespace to trigger
type-ahead-find, so that the key focus is moved briefly to the
search entry and back to the stage, resulting in a disruptive
flickering of the entry.
Fix this by excluding whitespace from triggering type-ahead-find.
https://bugzilla.gnome.org/show_bug.cgi?id=694475
xdndHandler used to wait for the stage to show up before calling
global.init_xdnd() . Since commit 65303d027a xdndHandler is initalized
later so the stage might be already visible at this point causing the
show signal never to be emitted and thus global.init_xdnd will never
be called.
Fix that by checking by calling global.init_xdnd without waiting for
the stage's show signal to be emitted, as the stage is guaranted to be
visible at this point.
The key was removed from gsettings-desktop-schemas, GNOME should
always draw a background: the key existed to support xsetroot, but
we no longer read the _XROOTPMAP_ID.
https://bugzilla.gnome.org/show_bug.cgi?id=694463
g_str_has_prefix() will assert when passed NULL, so we need to make
sure that we are passed a non-NULL log_domain first.
Spotted by <goughost<at>yahoo.com.cn>
https://bugzilla.gnome.org/show_bug.cgi?id=663601
We add some horizontal padding to the AllView's content to make
sure content does not end up underneath the scrollbar; while this
is not required in case of the FrequentView which does not have
a scrollbar, applying the same padding ensures that both views
end up with the same spacing, which makes switching between them
less disruptive.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
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
