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.
