If we detected that Bluetooth devices were setup, show the Bluetooth
menu so that users can easily turn Bluetooth back on.
This is a bit of a hack, as we cannot detect whether there is a
Bluetooth adapter at all when it's disabled, so we cannot tell whether
there were any Bluetooth devices setup, at some point. This state is
saved in the gnome-shell GSettings in the had-bluetooth-devices-setup
key.
Checking whether we saw Bluetooth devices at one point is a good
enough guess of whether there will be some in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=723848
It's very unexpected that a spinner animation would
preempt idles from running.
This commit runs the spinner animation with a low
priority to ensure it doesn't take over the main
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=754814
Right now the spinner animation updates every 14ms.
60 frames per second would be one frame per 16.667ms,
so we're waking up more frequently than we need to.
This commit changes the wakeup to happen after 16ms.
https://bugzilla.gnome.org/show_bug.cgi?id=754814
If the source actor is sized 0x0, the grabHelper will close the menu
on button release if the menu ends up flipped because in that case the
release event happens when the pointer is neither over the source
actor (since it's 0x0) or over the menu actor. A zero sized source
actor works for the non-flipped menu case because the menu's actor
itself ends up underneath the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=756605
If we get another effect on the same actor, we should make sure to
remove the clone through the "overwrite" methods provided by Tweener, or
there will be a race that might end up with a stray clone being left
around.
https://bugzilla.gnome.org/show_bug.cgi?id=756714
The translation should describe the difference between the fullscreened
and unfullscreened position of the window - however we are currently
assuming a fullscreen position of (0, 0) instead of the monitor's origin,
which causes glitches on dualscreen setups.
https://bugzilla.gnome.org/show_bug.cgi?id=756697
Some labels in the system status menu - namely network names - are out
of our control, and may thus grow the width "infinitively" unless we
restrict the menu width. So far we have been doing this by setting a
fixed width or max-width, but any value we put there might end up
being too restrictive in some locales. Instead, request a width that
fits all the labels we want to show unellipsized and use that instead
of an arbitrary limit.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
We use the newly introduced feature from Mutter to hook up our own
fullscreen and unfullscreen animations.
To give the illusion of a transition as smooth as possible, we create a
snapshot of the current contents of the actor before its state is
changed, and crossfade between the two states while the size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=707248
StIcon will skip loading the texture when its theme node is unset (which
may happen on style changes while the widget is hidden). While our size
request to compute the dash icon size will create the icon's theme node
if necessary (and of all its parents), a missing texture can still throw
off our computation.
Make sure this doesn't happen by ensuring the icon's style first, so the
texture is updated in response to StWidget::style-changed if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
When adjusting dash icon sizes, we compute the icon padding by subtracting
the configured icon size from the first icon actor's preferred size. To
make sure that the preferred size correctly corresponds to the current
dash icon size even while the icon is animating, we enforce the size
before the size request. For that we used to temporarily manipulate
the icon texture size directly, but commit e92d204d42 cleaned this
up to use the setIconSize() method instead.
This does not work however, as the icon actor's iconSize property will
always match the dash iconSize property, making the method a noop. So
go back to the original approach of enforcing the texture size to make
sure we always base our computations on correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
There is nothing particularly critical about this notification, it
was only marked as such to get certain behavior like auto-expanding
and sticking-around to be acknowledged by the user (as it offers
more actions than the summary notification, so it is frustrating
when it goes away because it was missed).
As all notifications will now stay visible until we are sure the
users has seen them, the latter reasoning no longer applies.
Auto-expansion doesn't appear too important and may even be considered
annoying by users, so remove the CRITICAL hint now.
https://bugzilla.gnome.org/show_bug.cgi?id=657923
We are currently erroring out when the tab chain doesn't contain at
least one window for an app which might happen for windows that don't
take focus like xeyes. This leaves us in a state where we can't show
the switcher at all. Let's just ignore these apps instead of looking
broken.
While the GtkSettings::gtk-shell-shows-app-menu property is meant to
reflect a desktop capability (i.e. in the GNOME case: the app menu is
shown in the top bar), it is possible for users to overwrite it.
Respect the setting and actually hide the menu in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=745919
Refer to the system menu in the top bar as "System" rather than "Settings" as
it contains more than just settings and "Settings" is already used for the
settings panel. "System" is also used elsewhere, so include context for
translators.
The destroy signal handler is kept connected despite the NotificationMessage
being destroyed, which leaves dangling NotificationMessage objects that will
be mass destroyed when the Notification object these depend upon is finally
destroyed.
Depending on the amount of accumulated NotificationMessages, this may lead
to temporary freezes or other more funky issues when recursion limits are
hit.
https://bugzilla.gnome.org/show_bug.cgi?id=755425
When loading several animations at the same time, the last call
overrides the result for all of them.
This commit caches all animations separately based on the source's
schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=741453
We currently will always allocate the user list's preferred size, so it
will grow indefinitely and never scroll; limit the height instead to
get the desired scrolling behavior when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=754525
When the user successfully types their password, we should hide
the spinner from the button well right away, so it doesn't
consume resources until reset (which may happen significantly later
if the user is vt switched away)
https://bugzilla.gnome.org/show_bug.cgi?id=753891
The code previously tried to stop spinner after it was hidden, but
due to an incorrect check was only stoppig it after it was shown.
Also, it was only stopping after hiding due to an animation, and
failing to stop it in the non-animated case.
This left the spinner hidden and running while VT switched away
from the login screen, only stopping when the auth prompt was
reset when switching back.
https://bugzilla.gnome.org/show_bug.cgi?id=753891
* switch to a one-column layout (and adjust strings/widths
accordingly
* remove separator before system menu
* add link to account settings to user submenu for consistency
https://bugzilla.gnome.org/show_bug.cgi?id=751377
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.
This fixes a bug introduced in commit 3c8c5a5570 that leads to the
user session crashing when the login screen is reactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
We fade out the authentication prompt when a user successfully
logs into a user session. We reset it and fade it back in when
the user switches back to the login screen VT.
The problem is, we only fade it back in if the auth prompt status is
VERIFICATION_SUCCEEDED. It's possible for it to be NOT_VERIFYING
if the authprompt gets reset for some other reason in the interim.
This commit changes the check to be more precise. We now only skip
the fade-in, if we're already faded in, and we only skip the reset if
we're already reset.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
If there's a caret or focus move we should delay it until the pointer
is stationary for a little while so as to avoid jittery and spurious
viewport movements.
https://bugzilla.gnome.org/show_bug.cgi?id=752138
The user should be allowed to cancel if verification hasn't
started yet and they're typing in their username. This
commit changes the authPrompt cancel function to not
ignore such requests.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
This commit addresses that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
If the next button ever gets set to Sign In, it won't
get reset to next until the next question asked by pam.
This commit ensures it gets reset to Next when asking
for the username.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
This object (not really a Clutter.GestureAction) sets up a captured-event
handler, which exclusively looks for 4 finger touchpad swipes, emitting
an ::activated signal under the same terms than WorkspaceSwitchAction.
https://bugzilla.gnome.org/show_bug.cgi?id=752250
We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen.
The object already handles getting called when there is
nothing to cancel, so just cancel it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=752438
shell_global_get_overrides_settings() may return %NULL in case of
custom shell modes (i.e. not the default and classic ones); while
this is not officially encouraged, we should still handle it rather
than throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=751921
The control center will call this method when the configuration dialog
for a display opens/closes, which will cause the same labels to quickly
fade out and in again, looking like it's flickering.
This commit fixes the issue by removing the tweens altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=751599
In some cases we might be allocated a size such that
this._grid.topPadding and this._grid.bottomPadding are both 0 which
means that the ScrollView fade effect gets removed. In that case don't
try to access the effect since it will be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=750714
The menu items to move a window to the left/right workspaces were
removed when the window menu was implemented in GNOME Shell. This
is OK for the default vertical layout but not for alternatives.
https://bugzilla.gnome.org/show_bug.cgi?id=751344
And make these only handled on wayland. There's a plethora of issues
around touch passive grab and touch/pointer doubly handling to use
these right away on X11, so we stick to single-touch/pointer there.
This reverts commit 032a688a72.
https://bugzilla.gnome.org/show_bug.cgi?id=750287
Instead of using gnome-settings-daemon's D-Bus interface's presence.
iio-sensor-proxy now offers a D-Bus interface, which will exported
"HasAccelerometer = true" when an accelerometer is present.
https://bugzilla.gnome.org/show_bug.cgi?id=749671
Just reuse this gesture rather than implementing edge detection ourselves.
As a plus, we might get touchpad swipe support when Clutter handles it.
https://bugzilla.gnome.org/show_bug.cgi?id=749742
The menu is clearly associated with a particular window, so keeping
it around when the window is gone doesn't make sense - in case of
the window menu, it is actually harmful as every action will act on
the invalidated window and result in a crash. So just dismiss the
menu when the menu is unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=749529
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
For barriers like the hot corner which are made up of multiple axis
barriers, make sure that all the barriers have been left before
resetting the barrier.
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
According to systemd logind's documentation, the CanSuspend() method
"returns 'na' in case "the operation is not available because hardware,
kernel or drivers do not support it", while "'no' is returned if the
operation is available but the user is not allowed to execute it".
See http://www.freedesktop.org/wiki/Software/systemd/logind
Thus, we need to return true here when the reply for the CanSuspend
method is neither 'no' nor 'na', or we would providing false positives
in cases where suspension is simply unsupported.
https://bugzilla.gnome.org/show_bug.cgi?id=748338
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
The window menu has all those workspace related options, but with multiple
monitors, it is much more interesting to quickly move a window 'over' to the
other monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=633994
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
Pause dynamic workspace management while workspaceSwitcherPopup
is shown so as to eliminate infinite creation and destruction of
workspaces, thus preventing stuttering while trying to move a
window to last workspace.
Add _isWorkspacePrepended flag to make sure only a single workspace
is prepended at a time thus preventing the possibility of prepending
infinite workspaces while dynamic workspace management is on pause.
Prepend a new workspace by creating a new workspace instead of only
shifting the windows to next workspace so that the workspaceSwitcherPopup
may appear in sync with what's happening behind the scene and display
correct number of workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=712778
User read time per character has been changed from 16ms to 48ms because the
message of information about last login is displayed for half a sec that is not
a good user experience. So time to read a character is increased to 48ms from 16ms.
https://bugzilla.gnome.org/show_bug.cgi?id=720885
To switch workspace by keyboard in the overview, the user currently
has to use the normal keybinding. However as the vertical alignment
of workspaces makes them very similar to pages in the app picker, it
makes sense to also support the standard pageUp/pageDown keys.
https://bugzilla.gnome.org/show_bug.cgi?id=742581
"Moving" a window to another workspace doesn't make sense when it cannot
be unstuck, and is potentially confusing if a new workspace is added at
the start/end - just don't do anything in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=746782
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
Currently the menu position below the button means that the menu
can extend to roughly half the screen height before ending up partly
off-screen. This is plenty of space for commonly installed sessions,
but some users have a significantly higher number of sessions in the
list. Move the menu to the side of the button in that case to maximize
the vertical space the menu may take up.
https://bugzilla.gnome.org/show_bug.cgi?id=734352
There is currently no way to trigger an icon's right-click menu by
keyboard. While there's a good chance that the icon will ignore
<shift>F10 and similar shortcuts, passing on key events will at
least make it work for some icons ...
https://bugzilla.gnome.org/show_bug.cgi?id=746487
While legacy status icons lack a proper accessible name of their own,
we can try to find the corresponding application or the icon's window
title - hopefully most status icons provide at least one, so they
don't show up completely "blank" in screen readers.
https://bugzilla.gnome.org/show_bug.cgi?id=746487
g-s-d has been taking care of this for us but in a very hackish way
that causes dconf writes on every startup and also doesn't handle
dynamic updates to locale1's properties which has become a problem now
that GDM keeps its greeter session running in parallel with users'.
To take care of this properly, this commit introduces a settings
abstraction with both system and session implementations. The session
implementation just wraps access to the existing gsettings while the
system one gets its values from org.freedesktop.locale1's properties.
https://bugzilla.gnome.org/show_bug.cgi?id=746288
There's some vestigial code for hiding the user list
that runs at the same time its parent is hidden.
Only the parent should be hidden, at this point, so
there's situations where the user list hides and
never comes back.
This commit fixes that, by deleting the vestigial code.
https://bugzilla.gnome.org/show_bug.cgi?id=719418
Since commit 75745fc23f, the bodyStack itself is no longer start-aligned
to not break custom body actors like chat notifications. However we still
want "normal" body actors start-aligned to get the correct RTL behavior.
We now stopped using notification actors directly for anything, so
we can simplify the Notification class significantly by turning it
into a purely informational object others can use to built their UI
representation from.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Special-casing banners of resident notifications was really a
thinly veiled special case for chat notifications, as those were
still using the old notification actor which coupled the life-time
of the notification to its actor. This is no longer the case, so
we can do the sane thing and destroy banners once they are no
longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
We currently use the setActiveSession method to both mark a menu item as
selected, and also tell gdm about the current session the user selected.
Since gdm is ultimately in charge of the state, we should decouple this
and simply ask gdm to set the session, and have the menu item reflect
what gdm thinks is the current session.
This prevents state getting mismatched and oscillations from happening,
where we get in a loop of constantly telling gdm what the session is.
https://bugzilla.gnome.org/show_bug.cgi?id=740142
If a smartcard is missing from the reader when we start up,
and the system is configured to disable password authentication,
then we need to ask the user to insert their smartcard.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=740143
It makes sense for the gesture to reflect the position of the
activities button / dash. In RTL locales, those are located on
the right rather than the left, so make the gesture apply to
the opposite edge in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737502
Instead of listening to a dbus property exported by g-s-d, listen to the
MetaBackend signal telling the last interacted device, and make sure we
only show the keyboard for touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=745977
While legacy status icons are notoriously bad with regard to
accessibility (well, among many other things), we should still
make them available via ctrl-alt-tab ...
https://bugzilla.gnome.org/show_bug.cgi?id=746022
Currently dismissed events will simply reappear when browsing
back and forth between dates, which is clearly broken. Instead,
hide events that have been dismissed permanently. For now, we
simply store a list of ignored IDs ourselves, until we get API
in evolution-data-server to reliably store custom per-event
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=660293
The design calls for differentiating between dismissable reminders
and permanent events, based on whether the selected date is "today"
or some other day.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
While messages in the EventsSection are currently simple enough to
use the generic Message baseclass, the design calls for events to
only be dismissable on the current day. We will need a subclass to
implement this behavior cleanly, so add one.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
As the design calls for slightly different behavior for the current
day, move the _isToday() function out of MessageListSection to have
it available elsewhere as well ...
https://bugzilla.gnome.org/show_bug.cgi?id=744927
Currently the clear action in the section header simply removes all
messages from the section. While the result looks exactly as if the
close button of each individual message had been clicked, the messages
are not actually closed - after a restart (or some other condition that
triggers a reload), the messages simply reappear, which is confusing.
Do the expected thing instead, and make clear close all messages in the
section.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently a message can only be closed by its close button. However
as we want to make a section's clear action synonymous with clicking
the close button of each individual message in the list, we will need
to expose the close action, so add a corresponding method.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently closing all messages is subtly different from clearing
a section, which is confusing. Start making the behavior more
predictable by only showing a close button in the message when
the section's clear button would remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
This closes a race between setTerms and a slow GetInitialResultSet.
The bug manifests as follows:
- initial search for a short string
- previous results === undefined, call GetInitialResultSet
- user types more, cancel previous search in setTerms()
- mainloop, then _gotResults([])
- previous results === [], !!previous results === true
- therefore call GetSubsearchResultSet with an empty list of results
- _gotResults() from GetSubsearchResultSet is empty
- much later, return from GetInitialResultSet is discarded by
cancellable
- user unhappy because what he searched for is not there
After this fix, the flow is:
- initial search for a short string
- previous results === undefined, call GetInitialResultSet
- user types more, cancel previous search in setTerms()
- mainloop, but no _gotResults
- previous results === undefined, call GetInitialResultSet again with
longer string
- some time later, return from first GetInitialResultSet is discarded
by cancellable
- soon after, return from second GetInitialResultSet comes with good
results
- user happy
https://bugzilla.gnome.org/show_bug.cgi?id=745861
If a different message ends up underneath the pointer at the end
of the removal animation, it won't receive an enter event until
the pointer is moved, and thus its hover state will not be correct.
Fix it up manually with an explicit pointer sync.
https://bugzilla.gnome.org/show_bug.cgi?id=746019
As we use two separate body actors for expanded and unexpanded
notifications, updating only one of them on notification updates
is not enough - if the notification has already been expanded,
we need to update the second label as well.
There's a strong expectation that delegating or presenting a channel
will result in a window being activated, so close both overview and
calendar as we do elsewhere.
Enabling line-wrapping of the unexpanded body is not enough to enforce
a single line when the text has embedded newlines, so replace these with
spaces (this is similar to setting ClutterText:single-line-mode, however
that would use a paragraph separator glyph instead).
If activateWindow() is called as the result of activating an item
in the Time & Date drop-down (most likely a notification), it should
behave as other items and close the calendar.
NotificationMessages set the icon either from the corresponding
notification's gicon property, or fall back to the source icon.
Except that we never actually set a notification's gicon property to
the provided icon, so we currently just always fall back, whoops!
If users click outside the search entry while it's empty we reset and
thus give up key focus. This means that when using an input method
with candidate popups, interacting with the popup with a mouse click
cancels the current input method context if there's no other text in
the entry besides the preedit string.
To avoid this we can check if the entry has preedit in addition to
checking if it has normal text.
https://bugzilla.gnome.org/show_bug.cgi?id=745167
Ideally we would allow navigating into the button in the screen
reader case, so the configured clocks are read out properly.
However we can still do better than nothing short-term by pointing
to the section header as the button's label_actor.
https://bugzilla.gnome.org/show_bug.cgi?id=745393
Currently both the timestamp and the position in the notification list
are static once a notification has been added; however notifications may
be updated later, in which case those properties should be reevaluated.
https://bugzilla.gnome.org/show_bug.cgi?id=745132
On locales that support it, time formats should follow the 12-hour/24-hour
preference, which implies that they should be updated when the setting
changes. So add another utility method which creates a label for a specific
time and keeps it in sync with the format setting.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
The world clock uses GLib.DateTime instead of the built-in Date type
because of the much superior timezone support, and therefore cannot
use the new formatTime() helper. To make this possible, modify the
method to support a parameter of either type.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Replace the time formatting in notifications and events with the
new utility method - this makes sure that all times are now following
the clock-format setting and use LC_TIME.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Displaying a time is more complex than it appears at first glance:
it should respect the user's choice regarding 12- our 24-hour format (but
only when supported by the locale) and follow the LC_TIME rather than the
LC_MESSAGES setting.
So rather than getting it more or less right in various places, it makes
sense to defer to a helper method which hopefully does the right thing. The
method added by this patch is based on _formatTimestamp in telepathyClient
with some minor tweaks:
- there's an additional params parameter which allows enforcing
a time-only format, even on dates other than the current one
- only a single desktop settings object is created and shared between
invocations
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Currently scroll events during the swarm animation will make the
grid appear immediately in addition to the animating clones, and
there'll be a mismatch with the icon at the target position. This
badly breaks the illusion of launchers emerging from the dash and
positioning themselves in a grid - as scrolling icons "mid-air"
before they form a paginated grid doesn't make much sense anyway,
fix this issue by ignoring scroll events for the duration of the
animation.
https://bugzilla.gnome.org/show_bug.cgi?id=745574
These notifications are annoying for the most part: presence
changes happen inside an app (empathy or polari), and that app
should have in app notifications for errors, instead of spamming
the global notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=745503
The previous code was applying the per row scaling factor of the current
row to the cumulative sum of all previous rows when calculating the y
position of a row. This resulted in the row being shifted up so it would
overlap other windows when the previous rows were not using the same
scaling as the current one.
Also the previous code was not considering that the spacing does not get
scaled when calculating the scaling factor. This is wrong as well and
could result in the overview overlapping the workspace switcher in
situations with lots of windows open.
This fix gives each row the appropriate height according to its scaling
factor and then ensures that the grid remains vertically centered after
losing some of its height.
https://bugzilla.gnome.org/show_bug.cgi?id=744883
Clients can be expected to deal with the WM going away temporarily,
but not the display server - so when running as wayland compositor,
a restart is generally a fancy way of killing the user session, and
there's little we can do about it except for preventing the user to
shoot herself in the foot by throwing an error.
https://bugzilla.gnome.org/show_bug.cgi?id=741665
While those elements cannot be activated, they still provide useful
information to screen readers, so include them in the focus chain.
For the same purpose, set a more verbose accessible name, given that
it is not bound by the same space constraints as the visible label.
https://bugzilla.gnome.org/show_bug.cgi?id=706903
It doesn't make much sense to show a section if it must remain empty
due to the session mode - there won't be any events if the session
mode disallows events, or notifications if those are disallowed. So
take the session mode into account and update the sections' visibility
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
We currently show the world clocks section unconditionally, even when
the session mode disallows launching the Clocks app to configure the
displayed clocks. This does not make sense, so hide the entire section
when the session mode disallows settings.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
Commit 5a8923ef95 removed support for legacy status icons from
the notification system, as we no longer want them to appear as
notifications. As we are unfortunately not quite at a point where
we can remove all support for them for good, so we now need an
alternative place to put them. Add a small dedicated tray at the
bottom which appears when any legacy status icons are active. By
default it is almost completely hidden to not interfere with the
user's windows, but can be expanded on demand to interact with
the icons.
https://bugzilla.gnome.org/show_bug.cgi?id=745162
polari is the GNOME app for IRC, empathy is for everything else
So prefer polari to empathy for IRC channels. We don't need
to check that either exists (even though polari is not a core
app) because mission control tries every handler if the preferred
one fails.
Depends on bug 745418 for polari to be mission control activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=745431
Make sure the message list section is set to the current date
when opening the menu, otherwise the calendar might skip
the selected-date-changed event (because the day did not change)
which would leave the message list with an uninitialized date.
https://bugzilla.gnome.org/show_bug.cgi?id=745412
Turns out this makes interaction with the OSK or candidate popups
using a mouse basically impossible since they get dismissed when the
key focus is captured by a window in the overview.
This reverts commit aeb9f5775f.
https://bugzilla.gnome.org/show_bug.cgi?id=745245
Messages can be dismissed using a pointer device by clicking the
close button, there's no reason to not make the same action
available via keyboard as well. Delete looks like an obvious
choice ...
https://bugzilla.gnome.org/show_bug.cgi?id=745279
The overview has a longer life-time than dash items, so we are
leaking a signal connection each time an item is destroyed.
Spotted by Michele (<micxgx@gmail.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=744575
As it is impossible to interact with notification banners while a DND
operation is ongoing, we can temporarily hide the banner container from
picks so that DND works as expected even while a banner is showing.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
Since commit e189a34, the trayBox uses a Contraint to cover the primary
monitor's work area. This allows banners to be clipped so they don't
leak into monitors above the primary one during animations. However even
without being reactive, the trayBox now interferes with operations like
Looking Glass' object picker and overview DND.
With the trayBox no longer being positioned manually, there's no strong
reason to keep it in LayoutManager, and handling it in MessageTray allows
to hide the actor while no banner is showing, which helps with the issue
outlined above.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The actor is supposed to be hidden while no notification banner
is displayed, and in addition to that when banners are temporarily
blocked (because the calendar is open). However the current code
always shows the actor when banners are not blocked, fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The screen should be woken up when a new notification is shown on
the lock screen, but not when a notification arrives while disabled.
Add a missing condition to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=744114
The problem is caused by '_askForUsernameAndBeginVerification' being
called multiply times. So when we click 'next', the old connected
function will also be executed.
The mode is never set after the removal of the bottom tray, so it
no longer makes sense to pass it to allowKeybinding(). We can also
safely remove it from the ActionModes flags altogether without
requiring a synchronized update with gnome-settings-daemon, as
the latter never used any flag value above LOGIN_SCREEN.
When it comes to keybindings or gestures, there's not really a good
reason why popups associated with the top bar should behave differently
from any other shell menus. Just set the action mode generically for
all menus, so actions like screenshots or media-keys start working
with menus like the background- or app launcher context menus.
https://bugzilla.gnome.org/show_bug.cgi?id=745039
We reuse the old body text on useMarkup changes and for expanded
labels. However just taking it from the label actor does not work
when markup is used, as once applied it will be stripped from
ClutterText:text.
So to preserve markup, keep our own copy of the original string
around.
https://bugzilla.gnome.org/show_bug.cgi?id=744907
Markup in notification titles is not support (and never has been).
Therefore the text is run through g_markup_escape_text(), and as
a result we do have to use markup internally to correctly show
legal-but-escape characters like '&' or '"'.
https://bugzilla.gnome.org/show_bug.cgi?id=744894
The message indicator conveys that the message list contains unseen
messages that will not be shown as banner. So its visibility depends
on two factors: the number of unseen messages, and the number of
messages waiting in the queue to be shown as banner. As we currently
only update the visibility on changes to the former, the indicator is
not always accurate - for instance sources notify count changes before
passing on a notification to the message tray for display.
To fix, add a signal to the message tray to notify when the queue
changes and use it to update the indicator's visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=744880
Chat notifications are king of custom, so we'll leave them out for now
and keep using the old banner. However we can port the subscription
notification.
Hotplug notifications use custom notification banners to include
application icons in buttons. Bring those back by providing an
appropriate createBanner() implementation.
While we want to encourage the use of regular notification banners,
some of our built-in stuff does require more or less customized content
("more" being chat notifications, a.k.a. king of custom).
Account for this use case by delegating banner creation to a method,
so either Notification or Source subclasses can overwrite it.
Nothing except for the chat notification is really custom, so stop
specifying the flag for anything else - it will soon become a bit
harder to create non-standard notifications, so don't do it for no
good reason (discouraging this is of course the reason for making it
harder in the first place) ...
Instead of using the notification's own actor as a banner (and
keeping it around after the banner was displayed to not dismiss
the notification itself), create a separate banner actor from
the information the notification provides, just like we do for
lock screen and message list notifications.
This change breaks notifications with custom content, but only
temporarily - we will soon provide a hook to allow customizations
again.
We no longer have a single notification actor that is either displayed
as banner or reparented to the summary depending on state - both the
lock screen and the notification section of the message list create
their own UI based on the information attached to the notification
object. Adding to this that different representations of a notification
may now exist simultaneously (as they are included in the message list
immediately rather than after the banner has been displayed), it no
longer makes sense to keep the banner actor in the notification itself.
Add a new NotificationBanner class that provides a separate banner
implementation based on the message list's NotificationMessage that will
soon replace the existing notification banners.
Both the screen shield and the notification section in the message
list create their own UI for notifications rather than using the
notification actor itself. Currently there is no clean way for such
representations to include notification actions - we will need this
as we will soon use a separate actor for banners as well, so keep
track of actions added via addAction().
Notifications in the message list cannot be expanded, however we will
soon use NotificationMessage to re-implement notification banners, where
we still want actions and expanded content.
While this functionality logically belongs to the future banner subclass,
it is cleaner and easier to have the basic support in the base class.
This also leaves the door open for expanded notifications in the summary,
should that become a thing again.
The panel is not visible when in fullscreen, but critical notifications
may still be shown - having them pop out from where the panel would be
looks unpolished, so adjust the trayBox accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was removed as actors that should not affect the input
region can simply be added to the uiGroup instead. However
the property is useful to add non-reactive chrome, but then
use trackChrome() to add a child to the input region.
This reverts commit e62d22a50e.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Occasionally it makes sense to constrain to a monitor's work-area
rather than the entire monitor, so implement that behavior and add
a property to turn it on.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
St's hover tracking uses ClutterInputDevice, which unfortunately may use
an outdated cursor position to determine which actor is hovered. Using
MetaCursorTracker instead would fix this, but would require linking St with
libmutter - avoid this for now by manually fixing up Clutter's view of
the pointer position in the case where we rely on it working properly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
While applications can no longer spam the users with a constant stream
of banner notifications, it is still possible to drown the summary in
the message list. Avoid this by limiting the number of notifications a
single source is allowed to display simultaniously.
test-xy-stress in libnotify's tests suddenly became fun again ...
https://bugzilla.gnome.org/show_bug.cgi?id=744850
We want to shield users from being overloaded by an overwhelming stream
of notification banners, either due to coming back from idle/lock or
because an application is misbehaving. Previously we replaced all queued
notifications with a summary notification in that case, but now that
notifications appear in the summary immediately, we can simply stop
adding them to the queue and rely on the date menu to convey that
information to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The summary may contain notifications that have not been seen by the user
and won't be shown as banner. Currently this is only the case for resident
notifications that are emitted by the focused app, but it will become more
common as we will start limiting the number of queued notifications.
Indicate to the user that more notifications are available by displaying a
small dot in the top bar button.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Source::count-updated is emitted as notifications are added or removed,
which is correct for the primary notification count. However it is not
for the unseen count, which will also change when a notification is
acknowledged without being removed. At the moment this does not matter,
as the unseen count is only used on the screen shield and notifications
are never acknowledged while the screen is locked. However we will soon
use the unseen count in the normal session as well, so emit the signal
in this case too.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Using a "There are too many notifications" notification is a bit odd,
and we will address the issue differently soon. So rather than update
the notification to do something else than opening the mostly empty and
useless tray when clicked, remove it altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
No Source subclass used it to do anything special, and with sources
no longer having any UI representation on their own, doing anything
else isn't useful either, so just kill off that hook.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was a nice feature, but with sources no longer being represented in
the UI, there is no longer a way for users to make use of it. If we want
to bring the feature back in the future, it would probably make more
sense to implement via the chat source's policy anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The notification list in the calendar drop-down now functions as summary
area, so we can drop it from the message tray and remove a lot of complexity
from the state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
There is not good reason why activating a GTK+ notification should
behave fundamentally different from fd.o notifications - we don't
raise the app because we expect it to perform an appropriate action,
but that does not include closing overview or calendar for us ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Just like we leave the overview when activating a notification,
the calendar popup should be closed - after all, the only case
where the calendar is open when a notification's default action
is activated is the user clicking an entry in the message list's
notification section.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Since notification support was added to the lock screen, notifications
are no longer necessarily represented by the actual notification actor
anymore. However when an existing notification is updated, external
representations currently become outdated.
Emit an appropriate signal which allows them to update.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
As the popup's height depends on its content, which itself varies
depending on the selected day, browsing the calendar can result
in distracting size changes. To avoid this, the design calls for
the height to be frozen to the previous one in that case.
As the popup will always open with the current day selected, we
don't have to be very sophisticated and can just lock the popup
to the height corresponding to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is not only a replacement for the calendar events
list, it will also take over the notification summary from the
message tray. As we start drawing events from other sources than
calendars, hiding it based on whether or not any calendars have
been set up is no longer appropriate, so always include it in the
calendar drop-down now.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is a scrollable list that will hold sections of
different types of time-related messages like notifications,
calendar events or birthday reminders. When no section displays
any content for the selected date, a placeholder is shown instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will start using both URLHighlighter and the _fixMarkup() helper
method the same way it's used in MessageTray. Usually we should
make fixMarkup() public and call the existing methods, but we are
planning for them to go away soon, so just keep two copies until
the original one is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will soon replace regular menu items in the calendar drop-down
with more complex elements.
However there will still be items that should close the drop down
when activated - rather than making the menu available throughout
the hierarchy (and eventually from outside as well when we add the
notifications list), have a public method on a global object just
like the ubiquitous Main.overview.hide().
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Menu items are on their way out of the calendar drop down, so let's
start with the easy one. This one is removed without replacement,
but then the Date & Time panel should be a one-time stop for most
users anyway, so not having a direct shortcut should not be much of
a problem. It is also the last remaining Settings item outside the
system menu ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The new design has the events list on the left and the calendar on the
right, so swap them around and remove the vertical separator between
them in favor of some additional whitespace as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
So we can style it differently than :hover.
We already have a active state for the menu items which includes
more than hover. For example, when the keyboard focus moves to a item
or we select programatically a item.
For this reason we need a style class named active for the meaning we
give to it in menu items, and a pseudo class active with the meaning
CSS has.
https://bugzilla.gnome.org/show_bug.cgi?id=744680
Don't assume struts are on the primary monitor while computing
the strut side. Instead, find the first monitor that overlaps the
strut and compute the strut side using it.
https://bugzilla.gnome.org/show_bug.cgi?id=744183
This capability was only really useful for media players, and with
music notifications no longer being special, we can simplify a bit
by removing support for it.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Music is no longer a special type of notification according
to the design. If we want to resurrect the functionality, we
can reimplement it with a dedicated API like MPRIS rather
than piggy-bagging on the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
According to the design, hotplug notifications should no longer offer
an eject action and use regular notification buttons (but using icon
and text), the default action when clicking the notification itself
is to launch the file browser.
Also as the corresponding resident notification is gone, it no
longer makes sense to make the notification transient.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
The new notification system will no longer give access to actions
from the notifications list, so a notification that is never
displayed as banner does not make sense here.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Tray icons make for a terrible UI on their own, but trying to
shoehorn them into the notification system has only made them
worse. At least for the time being this removal is temporary
and support for tray icons will be back, but no longer as part
of the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Users currently can't switch VTs while at the login screen.
This commit fixes that, by adding the relevant keybindings
to the login screen's allowed keybindings list.
https://bugzilla.gnome.org/show_bug.cgi?id=744800
drawing cursor is on by default, so the code:
if (options['draw-cursor'])
recorder.set_draw_cursor(options['draw-cursor']);
never lets you unset it.
Fix is to use 'draw-cursor' in options instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744599
When opening a panel menu, we set it's max-height to the available
work-area height to keep menus with scrollable content from growing
outside the monitor. However a menu that extends all the way down
to the bottom edge does not look great either, so also take margins
into account here.
https://bugzilla.gnome.org/show_bug.cgi?id=744498
Ouch, classy - we are telling translators to use a '24h' time
format for the '12h' time format string.
Luckily, only a handful of translations actually followed the
comment (de,hu,id,is,kk,nb,nl), and most of the corresponding
locales do not support 12-hour format anyway (only is_IS, at
least on Fedora).
We assume that applications that export a 'new-window' action can open
a new window, so we add an appropriate entry to the context menu.
However this duplicates functionality if the application already
exposes the action via the desktop file - don't add our own entry
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=744446
This DBus API is intended to be used by gnome-control-center's
displays panel to show monitor labels.
Each output (i.e. hardware monitor) identified by its
org.gnome.Mutter.DisplayConfig API ID has at most one label. On
mirrored setups, all the labels for outputs corresponding to the same
logical monitor (i.e. showing the same contents in the same mode) are
shown together.
At most, only one DBus client at a time is allowed to show labels.
https://bugzilla.gnome.org/show_bug.cgi?id=743744
Because there's nothing (in single-monitor setups) that could
take the drop in this case.
* js/ui/appDisplay.js:
AllView._loadApps(), FrequentView._loadApps(): Pass
an isDraggable parameter when creating the AppIcons,
depending on whether the favorite-apps key is locked.
AppIcon._init(): Check for isDraggable in the params and
do not create _draggable if it was specified, to prevent a
drag from starting.
AppIcon.popupMenu(): Check _draggable before trying to call
fakeRelease on it.
* js/ui/dash.js: Dash._createAppItem(): Check AppIcon._draggable
before trying to connect to its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
In a lockdown scenario, where the favorite-apps GSettings key is not
writable, hide the menu items for adding and removing favorites from the
dash menu. Additionally, reject drops to the dash for DND.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
After the login banner is shown and hidden, the first user
in the user list becomes non-reactive. This is because the
banner is given an opacity of 0, but still allocated.
This commit fixes that by hiding the banner explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743370
Normally when a user uses the login screen to log in, the
login screen gets killed and the user session takes over
the display.
This doesn't happen for wayland sessions, though. Instead,
the login screen gets reset, and the wayland session is started
on another VT.
The greeter proxy object needs to be recreated after this reset,
since it's associated with state no longer coupled to the login
screen after the reset.
This commit moves greeter proxy creation to happen at reset time.
https://bugzilla.gnome.org/show_bug.cgi?id=743371
The code described by the comment was moved away in commit eda27d51,
so it is not misleading at best. It wasn't too useful to begin with,
so kill it off rather than moving it to the correct place ...
When using dynamic workspaces, a new workspace will be appended
when moving a window down to the last (empty) workspace. It makes
sense to extend the behavior in the opposite direction, and prepend
a new workspace when moving a window up from the first workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
New workspaces are inserted by shifting all windows on workspaces
below the insertion position down. As a result, when the new
workspace is inserted before the active one, we end up with
the illusion of a workspace switch. Instead, activate the workspace
on which the windows from the active one ended up.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
We are not supposed to mess around with OR windows, so don't try
to shift them to a different workspace. This fixes a warning with
newer versions of mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
We will soon allow to insert a new workspace by other means than
DND in between workspace thumbnails, so move the relevant code
to a new windowManager method.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
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
It is really annoying for the user to acknowledge multiple notifications
when they queue up. So, to prevent a notification flood that has to be
handled by the user one-by-one, a summarized-notification feature is
added which leaves a single summarized-notification for the user,
replacing multiple notifications if the number exceeds 1, which they may
or may not acknowledge. When this summarized-notification is acknowledged,
the message-tray is opened where they can view the notifications that were
summarized. This helps the user concentrate on his primary task
simultaneously informing them about the new notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=702460
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
Since the background rework, SystemBackground is no longer a transparent
actor that you have to stack on top of a solid background, it is an
opaque actor. Fix the color of the background actor, and remove places
where we were setting the background color underneath the system background
and expecting blending - in particular, we can always set no_clear_hint
on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=738652
When monitors change, the previous index might not mean the same
physical monitor anymore, in fact, it might become invalid. In the
latter case, we'll actually get a JS error when accessing
this.keyboardMonitor in _updateKeyboardBox() . To avoid this, let's
just always reset the OSK to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=738536
Incorrect braces meant that if the ShellUserVerifier was destroyed before
the call to fprintManager.GetDefaultDeviceRemote(), the reply would result in
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=738256
Most of the code handles the sources setting being empty and
InputSourceManager.currentSource being null because previously the
"model" (i.e. the sources list) was kept in gnome-settings-daemon.
But this is fragile and since we're now the canonical place where the
list lives we can force it to never be empty even if the gsetting is
empty or contains only invalid entries. Adding the default keyboard
layout in that case is the safest thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=738303
Commit a4475465f1 fixed the wrong alignment for the fully visible
control, but regressed the partially slid-out one; take the slideX
factor into account to get the right offset for both cases.
Controls that slide left are located on the left, so the offset to
align them with the corresponding edge is always 0. It's controls
on the right that need a different offset when the available width
exceeds the child's width.
https://bugzilla.gnome.org/show_bug.cgi?id=728899
Currently we use the same amount of total delay divided by all items,
but that makes the items animate slow if the amount of items is small.
To avoid that, use a smaller total amount delay for an amount of items
smaller than four.
https://bugzilla.gnome.org/show_bug.cgi?id=737017
This commit ensures the login screen gets focused after
the screen shield is raised.
The code affects the unlock screen as well, but it's
less important since the unlock screen gets destroyed
and recreated each time the curtain moves, so it
has an opportunity to take focus on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=708105
We currently allow infinite number of screenshot requests to be active at
the same time, which can "dos" the system and cause OOM.
So fail subsequent requests for the same sender when a screenshot operation
is already running.
https://bugzilla.gnome.org/show_bug.cgi?id=737456
We currently just clear out the map of recorders (which results
in the top bar indicator to be hidden), but don't stop the actual
recordings.
Spotted by Adel Gadllah on IRC.
Instead of waking up the JS every second to set the clock and update a
date label the user will rarely see, simply use property binding to
bypass JS string handling, and update the date in the menu when the menu
is opened.
Checks for a duplicate search before setting the current search
to true and before cancelling the current search. This ensures that
if a duplicate search occurs while the previous search is still active,
the duplicate search will not incorrectly cancel or change the state
of the previous search.
