When chrome is added with the trackFullscreen parameter, the actor's
visibility will be updated automatically whenever its monitor's
fullscreen state changes. However as we currently ignore the fullscreen
state at the time the chrome is added, the initial visibility may well
be incorrect - fix this by updating the initial visibility as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=749383
Since the introduction of per-source notification policy in commit
098bd4509b, the NotificationPolicy::enable-changed signal has been
used to track the 'enable' setting. However as we never actually
emitted that signal, this never worked without a restart - oops.
https://bugzilla.gnome.org/show_bug.cgi?id=749279
If we aren't the active session clutter can't animate and thus we
can't expect the shield to be shown before releasing the suspend
inhibitor so we should release it immediately when becoming inactive.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
The whole point of holding a suspend inhibitor is to be able to lock
before suspending.
Currently, when resuming we immediately take the inhibitor without
checking that we're locked which means that we won't be able to
release this inhibitor if we don't unlock at least once.
To prevent that and to better match the inhibitor's intention in the
first place, we can tie the inhibitor with not being locked. In
practice, we also want to let the locking animation finish before
suspending, so we'll tie the inhibitor with not being active
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
This could happen if we are VT switched away and an animated
activation is requested because we're preparing to enter sleep. Since
we don't animate in this case we'd never reach
_completeLockScreenShown() before coming out of sleep, at which point
we _inhibitSuspend() again and would leak the previous inhibitor.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
Commit 08690d658f generalized the banner-blocking behavior of the
dateMenu to all menus that would obscure the banner. However setting
up the 'open-state-changed' handler only when an indicator is added
does not work for indicators that change their entire menu (like the
app menu) - we currently end up with menus with no connected signal
handler, and throw an error when trying to disconnect an invalid
signal ID.
To address this, add a new PanelButton::menu-set signal and use that
to set up the 'open-state-changed' handler.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
We currently block banners while the time+date menu is open, as it
would obscure the notification. However it is not necessarily the
only menu for which this is the case, so generalize the behavior
to all menus that would overlap banners when open.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
As notifications appear in the time+date dropdown's message list, there's
a strong relationship between notification banners and the menu. However
while the time+date menu is centered by default, which matches the banner
position, its actual position depends on the session mode - in particular
it is moved to the right in classic mode.
Reinforce the relationship in these cases by moving notification banners
underneath the time+date menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
Unlike entries in the calendar's message list, banners are not subject
to the normal keynav chain, and making the banner actor itself unfocusable
allows for the focus to be moved to the action area when expanded.
https://bugzilla.gnome.org/show_bug.cgi?id=747205
Now that the tray is shown temporarily when a tray icon appears,
we can decrease its visible width when concealed to interfere less
with window content without hurting discoverability.
https://bugzilla.gnome.org/show_bug.cgi?id=746787
There is a balance to hit between discoverability and getting out
of the way, and the legacy tray currently fails in both regards.
To address the first issue, temporarily reveal the tray when a
new icon is added.
https://bugzilla.gnome.org/show_bug.cgi?id=746025
Resident notifications are not really a thing anymore with the new
design, so all the user sees are some notifications that mysteriously
cannot be closed. That's utterly confusing, stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=746860
libcaribou was designed to generate X events which works under wayland
sessions for X clients but obviously doesn't work for wayland clients
and for shell chrome.
This patch adds a simple caribou display adapter which inherits from
its X display adapter and allows us to continue to work for X clients
and at the same time makes the OSK work on shell text entries by
sending key events directly to the focused text actor.
Making the OSK work for wayland clients requires much bigger changes
at various levels in the stack and either not using libcaribou or
re-working it substantially so that's left for future work.
https://bugzilla.gnome.org/show_bug.cgi?id=747274
Sources are destroyed with their last notification. This is usually the
correct behavior, however in case of chat sources, the corresponding
telepathy channel might still be open, and any further messages that
should trigger a notification are lost because chat sources are only
created when telepathy's channel dispatcher notifies us about a channel
(via ObserveChannels).
Loosing messages like this is unexpected, so keep chat sources around
even without notifications while the channel is open.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Currently the lifetime of a chat source and its single notification
are tied together. While this apparently makes sense, it means we
will lose all follow-up notifications when a source is destroyed
with the corresponding telepathy channel left open. We will fix this
soon by tying the source to the channel's lifetime rather than the
notification, prepare for this by recreating the notification if
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
It's possible for a user to type their password so quickly
that GDM hasn't even had time to ask for the password yet,
much less have time to process the answer.
In that situation, we tuck the user response away as
_preemptiveAnswer, and pass it along to GDM when GDM is finally
ready for it.
The problem is, there's a bug in the code, where we send
null for the service name in the answer, instead of the right
service name (say "gdm-password").
This commit addresses the bug by making sure we don't pass the
answer along, until the service name is properly set in
_queryingService. To ensure that, answering query (answerQuery)
based on _preemptiveAnswer has been shifted right below
this._queryingService = serviceName;
https://bugzilla.gnome.org/show_bug.cgi?id=737586
Instead of saving only the current input source when entering password
mode, let's save the whole MRU list so that we can restore it when
returning to normal mode.
This is closer to user expectations since password mode is a transient
and short lived state.
https://bugzilla.gnome.org/show_bug.cgi?id=746605
If the login screen actors aren't placed at pixel
boundaries then they will show up blurred with fuzzy
text.
This commit ensures all actor allocations are floored
to integer coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=746912
We don't need a different GSettings object for each app or
favorite item.
While it practice it does not change much (AddMatch is still
obviously sent out), it minimally reduces the overhead on
changes, and makes for cleaner code.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
In recent glib, change notifications don't actually happen unless all
keys have been read, in an effort to reduce unnecessary dbus
traffic for shortlived GSettings object and avoid AddMatch calls.
But we care about changes here, so we need to make sure we're
subscribed, and an easy way to do so is to reuse the same object
to watch for changes and to load the active providers at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
When introducing support for "default disabled" search providers
this part was overlooked, so enabling a default disabled provider
would be ignored until the next login.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
When the chat app is focused, we should hide all banners immediately.
A good way to do so, without tracking which app is focused, is
to look for messages that are acked when the banner is unexpanded,
which implies they were acked by some other telepathy client.
https://bugzilla.gnome.org/show_bug.cgi?id=746364
