Trying to open an empty folder currently leaves the parent view in a
rather confused state. While we should look into fixing this in the
future, empty folders are not useful at all to begin with, so hide them.
https://bugzilla.gnome.org/show_bug.cgi?id=736910
The summary container will trap the focus if any sources are present,
making the message tray menu unreachable by keynav. Apply the same
hack as in searchDisplay and add a focusTrap to move the focus manually
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=707799
Can't wait to double the size of this list when these start using D-Bus
activation.
These were actually renamed in GNOME 3.12, but we couldn't do anything
about it before, and now we can.
It was assumed that BackgroundSource objects were always destroyed
on monitor changes because the BackgroundManager objects that hold
references were destroyed, but sequencing of updating of different
BackgroundManager objects meant that was not the case.
Properly update any cached Background objects held by the
BackgroundSource on a change to the monitor layout; in particular this
means updating animations in case they are multi-resolution.
All other submenus link to the corresponding settings, so we should
do the same for location - the privacy panel in this case, which now
sports a "Location Services" switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=736542
This lets us considerably clean up the event flow here and change how
things are structured. It also makes sure that we never show "No
Results" -- search.js not being aware of the timeout means that it might
not think that any work was being done when we show the page.
Keep a flag depending on whether a provider is in-flight, and use that
to determine what status label to show.
This ensures that we only show "No Results" when we're done searching
and we're sure that all providers have returned results back to us.
The complexities of tracking these two things separately, with the
display on one half, and the searching on the other half, is difficult
to manage. Squash it all together.
It is quite weird to have those calls/signals using WindowClone as an
argument, it is neater to pass MetaWindows around, and have each user
deal with their own representations of these.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
And use it to lookup the local WindowClone that applies. Otherwise,
WorkspaceThumbnail.WindowClone objects may be mistakenly set, which
are not usable interchangeably with Workspace.WindowClone ones. This
may lead to several misbehaviors as fields available in the second
object but not in the first one are accessed, some those undefined
values get used in math ops, which result in NaNs over the place.
Likewise, the similar functions in WorkspacesViewBase subclasses take
now MetaWindow arguments too.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
We don't really need this step as a separate method since all
implementations are supposed to be created and shown immediately. This
also ensures that we have items to show in all subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=735976
The enums values of geoclue have gaps in them (so more levels could be
added in future) but enum values of settings don't have such gaps so we
gotta translate between them.
Since desrt says that enums as integers in gsettings are bad, we now
treat accuracy level settings as string.
This fixes the recent regression of geoclue only allowing geiop level
accuracy to apps.
https://bugzilla.gnome.org/show_bug.cgi?id=736479
Since commit e04e507659, we will already get the right icon for the
submenu arrow, so we must not mirror it again. However we do need to
take the text direction into account for the rotation now (but that's
not actually too bad - the resulting code gets quite a bit easier).
https://bugzilla.gnome.org/show_bug.cgi?id=736343
Trust the heuristics in shell_app_can_open_new_window() to get it right
more often than not, and add an appropriate check in activate(). This
makes the behavior consistent with the dash, e.g. we will try to open
a new window (and show the corresponding animation) for apps that don't
have a "New window" item in their dash context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=736329
Commit 9e5704b introduced a regression due to a sloppy mistake not
making actors reactive on animation out.
Fix that making actors reactive when animating out as well.
The current code only works for enabled extensions, which means
that extensions that were marked OUT_OF_DATE cannot be enabled
without a restart when disabling the version check.
Fix this by reloading all extensions while making sure to only
enable any extensions when we're supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
Currently we consider the last item animating being the last actor of
the list, but that's wrong since the last item animating depends on the
distance between the source actor and the original position of the
animated actor.
Take that into account to check the last item of the animation.
The code that cleaned up when a background actor was destroyed tried to access
the Background as backgroundActor.background._delegate but when the destroy
signal is emitted, the MetaBackgroundActor was already disposed and
backgroundActor.background NULL.
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
When you open or close a PopupSubMenu the arrow icon rotates, but
the code previously assumed that the starting angle was a multiple
of 90. If you click the submenu fast enough the rotation could overlap
with the previous rotation and you'd get something that wasn't a multiple
of 90.
Now we ensure that the ending arrowRotation angle is always a multiple
of 90 regardless of what the starting angle is.
https://bugzilla.gnome.org/show_bug.cgi?id=728927
Although the actor are with opacity 0, they were reactive, so the if the
user quickly make a click on the grid while animating it can launch an
app accidentally.
To avoid that make the actors non reactive while animating.
