We check for (metasNeeded.length == 0) at the beginning of the function,
which is only ever called when when a non-zero number of results is
received back from the provider. Effectively, this means that
(metas.length != metasNeeded.length) will also catch (metas.length == 0)
and print a nicer message to the log.
The updateSearch() function is called in SearchResults every time new
search hits are available from a search provider; SearchResults will
wait for updateSearch() to complete in a callaback, to update the
overall progress of the search operation.
updateSearch() will call _ensureResultActors(), which will in turn call
getResultMetas() on the search provider, which is an operation that can
fail arbitrarily or return inconsistent data, as it's entirely in the
hands of the search provider.
In case _ensureResultActors() returns a failure, updateSearch() is
currently failing to notify the passed-in callback, which might leave
SearchResults in an inconsistent state: make sure the asynchronous flow
always ends up with a notification to the updateSearch() callback.
So that we'll recreate it the next time we want to show it. Otherwise,
we'll try to call things on a half-destroyed ResizePopup and end up
causing errors instead of showing the user their resize popup.
This will allow g-s-d to handle actions differently based on the
current mode - namely, allow the power button when locked, but
make sure to never show any dialogs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
Adding new parameters to the signal currently will break keybindings
until gnome-settings-daemon is updated to the new API as well.
Put additional parameters into a dictionary instead to make future
extensions easier.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
When animating workspace switches, windows on the old and new workspaces
are temporarily reparented. If windows are restacked, those windows will
thus be ignored by mutter until meta_switch_workspace_completed() resyncs
the stacking at the end of the animation.
As a result, activating a window on another workspace that is not on top
of the stack is very noticeably a two-step operation of switching workspace
and raising the window. There is a technical reason for that order[0], but
we can avoid the visible disruption by manually syncing the stack during
the switch operation.
[0] https://git.gnome.org/browse/mutter/tree/src/core/workspace.c#n590https://bugzilla.gnome.org/show_bug.cgi?id=741680
Just like keybindings and the message tray pointer barrier, gestures
don't always make sense - for instance, swiping up the screen shield
should not trigger the message tray just as the SelectArea action around
the left edge should not open the overview.
To avoid this, restrict gestures based on the current keybinding mode.
https://bugzilla.gnome.org/show_bug.cgi?id=740237
Frequently banner messages are longer than can reasonable
fit in a one column view, which leads to a smooshed layout.
This commit changes the layout to a two column view, with the
banner on the left and the prompt on the right, if the banner
message is long enough that it can't fit well above the prompt.
If there isn't enough space for two columns then we keep the
one column layout but add scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.
This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.
This commit moves the banner message to display when the user is
prompted for login credentials instead of when showing the user
list. It also adds a scrollbar if the message is too long.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen is pretty custom full screen container and the standard
layout managers aren't really a good fit for the kind of layout that's
happening. This will be even more problematic with upcoming changes
to login banners, so we need to switch techniques.
This commit moves login dialog over to using a custom allocate handler
that has specific domain knowledge of the parts of the login screen
and where they go.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
In certain cases the timeout for starting the calendar helper can
be reached but the calendar helper still loads fine. If so, just
ignore the timeout and wait until we get a notification from
dbus of the successful start.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
While the default Shell style is fairly decent with regard to
accessibility requirements, having the ability to tweak certain
aspects where the regular style works less well is still useful.
For this purpose, try to load a -high-contrast theme variant of
the default stylesheet when a high-contrast theme is requested
(as determined by the GTK+ theme name).
https://bugzilla.gnome.org/show_bug.cgi?id=740447
_hideDone checks _shown to determine if anything has shown the overview
while we hid it, and if so, shows the overview forward just in case.
In a local patch that called _hideDone immediately inside _hide for
testing, this broke. While we don't actually depend on this anywhere,
it doesn't hurt so that the next person to hack this up (perhaps me!)
doesn't get stuck debugging it for 20 minutes.
Since moving to a GFile based API in commit 642bf2b778,
setThemeStylesheet() no longer accepts %null to revert to
the default theme. We should have some way to revert to the
default and the least intrusive option is to return to the
old behavior, so do that.
Correctly computing the ISO week number is tricky and we already
have code in the platform to do it, so just refer its computation
to GDateTime rather than doing it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=736722
Using a separate property to show when the application is busy rather
than cramming it into the state property makes the code clearer. In most
places we only care if an app is running or not, not whether it is
actually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
If the user list is disabled and the user clicks cancel quickly enough
after typing their username, they can get in a state where the
auth prompt gets stuck in the insensitive state.
This is because the login dialog code makes the prompt insensitive
while while pam is processing the provided username, but the prompt
only makes itself sensitive again when it is hidden.
This commit makes it sensitive right before asking for a username again.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Once verification has succeeded, the train's already
left the building and we shouldn't allow canceling.
This commit renders the cancel button non-reactive
and makes the cancel function be a noop after
verification succeeds.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Due to a typo we were always removing the first (index 0) connection
from the global list of connections instead of the correct one.
This resulted in some connections remaining in the shell's connection
list long after they were removed. In particular, this resulted in
multiple copies of a bluetooth connection appearing after suspend/resume
(when the device was readded and the cached connection list was
rescanned).
https://bugzilla.gnome.org/show_bug.cgi?id=740227
I was going to add another DBus property to signal when the shell was
done loading and was idle, and while implementing that I noticed we
aren't emitting PropertyChanged for, well, any property. Let's fix
OverviewActive.
It's unfortunate it's so tedious to correctly implement a DBus
property =/
https://bugzilla.gnome.org/show_bug.cgi?id=704163
Currently, shellDBus only uses the passed in monitor index if it's
strictly > 0. A zero-index monitor is a valid one though, so don't
restrict this to strictly positive indices.
https://bugzilla.gnome.org/show_bug.cgi?id=740074
Commit 1291bcd0c8 implemented it for dateMenu, but the function
is already used in screenShield as well. Just add it globally as
we do for other standard gettext "macros".
Normally users switch xkb input sources and ibus input sources.
But currently the first input source only is running. It's also good
to preload all ibus engines in the logging session so that users switch
input sources quickly without the launching time of input sources.
The following is the ibus change:
https://github.com/ibus/ibus/commit/cff35929a9https://bugzilla.gnome.org/show_bug.cgi?id=695428
WorkspacesDisplay relies on being hidden to disable workspace switches
by scrolling or panning. Usually viewSelector will hide the previous
page on page switch, but we currently miss the case when opening the
overview at the app picker, where the workspaces page is still shown
for the transition, but never hidden.
Fix this by calling hide() in addition to setting the opacity to 0 at
the end of the overview animation.
https://bugzilla.gnome.org/show_bug.cgi?id=737534
Calling g_dbus_proxy_new without any flag means that the caribou
daemon will be launched through D-Bus activation, when creating
a proxy. It smoked out some corner cases in caribou and at-spi2-core,
but generally it would be good to avoid creating unused process.
This patch delays the invocation until the "Run" method is called.
https://bugzilla.gnome.org/show_bug.cgi?id=739712
Leading zeros are common in the 24h format, and indeed used in the
wallclock in the top bar. Convention and consistency within the
same clock format trumps inconsistency between different time formats,
so reverting commit 316f825b2a.
https://bugzilla.gnome.org/show_bug.cgi?id=658675
Splits instantiation of the event source into a separate method,
allowing extensions to subclass the DateMenuButton and provide its
own calendar source.
https://bugzilla.gnome.org/show_bug.cgi?id=672500
There is currently no simple way to inject into AppIcon's state change,
so an extension that wants to do this has to destroy/remove/update all
icons in the Shell (i.e. in the Dash, AllView, FrequentView) on enable()
and disable() after updating AppIcon.prototype._onStateChange, or the
extension must require a restart of the Shell.
To solve this issue, we rename _onStateChanged to _updateRunningStyle,
and connect the notify::state signal with an anonymous function that
calls _updateRunningStyle.
This extra function call should allow extensions to just extend the
updateRunningStyle function in the prototype.
https://bugzilla.gnome.org/show_bug.cgi?id=739497
This patch inlines the function _ellipsizeEventTime into its only caller
_addEvent. This also removes the need for the global const
EventEllipses and is thus removed by this commit as well.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
With commit dc6a60dde, the calendar displays the ending day and time of
a continuing multi-day event on its ending day. This results in the list
not appearing to be sorted. This patch sorts the list according to the
displayed day/time.
With the two appointments
Thursday 0800-1000 Foo, and Wednesday 0900-Friday 1200 Bar and today
being Monday, the rest of the week list currently displays:
F ...1200 Bar
T 0800 Foo
With this patch, the displaying order is switched because Friday comes
after Thursday.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
Currently, multi-day events are shown as individual appointments on each
day. This patch ellipsizes multi-day events to indicate continuation on
the prior or following day (or other time-period.)
The time label spot is now replaced by a box layout that contains the
prefix ellipsis label, the time label and the postfix ellipsis label.
In order to keep the alignment, ellipses are merely invisible (zero
opacity) when hidden.
The ellipses are styled using the events-day-time-ellipses class which,
by default, take the color of the event text.
When RTL is used, the box contents are adjusted accordingly (clutter
does that for us).
An event spanning three days now displays "...All Day..." in the
calendar on the second day.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
